Agile Team Building

Introduction

During  2014, in my start-up we had an agile training with Mr. Amr Elssamadesy the famous Agile trainer and the author of Agile Patterns: The Technical Cluster and Agile Adoption Patterns: A Roadmap to Organizational Success.

Mr. Elssamadesy joined the company during critical circumstances. Back then, we had new team of developers, business, and quality control and this team was considered as a "Junior"  team where as most of them were fresh grads or with 2-3 years experience in some cases. This was not the only problem, the major problem was that we had a mega huge product which was built during the previous 2 years that has a lot of very complicated features.

The major problem here is that, the very successful business team has sold this product to many clients and each client now are ready to operate and have their own very long list of requirements and customization needed. The product is really huge to the level that it is not very easily customizable. There wasn't any possible solution for the company to succeed by gaining the customer satisfaction. By very optimistic calculations, the new "Junior" team will take no less than 3 months to warm up and getting into the mode. Plus, the code base was really huge.

Team Building

 My major concern in this phase was the team itself. I will not go into more details about the team members themselves, or what was their psychology that took a lot of effort in the training, but instead I will go directly to the procedure of team building.

The team members - lucky us -  had very high technical capapilities .. they are code Gurus and Geeks by definition!
But how this team will work as a unit for the extremely hard task they have?

1. Agreements

Agreement 0: We work with agreements.

• Make.
• Confront.
• Renegotiate.

Agreements were the magical key that created the unity of the team. The "Zero" Agreement was only stated by Mr. Elssamadesy while the other agreements were set by the team as a complete unit. Agreements like: 'We Always Paire', and 'We Write Test First' were put and agreed by all the team members after a long discussions full of debates.

2. Test First

Testing is not an easy task. Glenford J. Myers, Corey Sandler, Tom Badgett in their book The Art of Software Testing stated that, the number of test cases available for a small piece of software that - for example- calculate the sum of 3 number is infinite number of test cases. While the art of testing is to know how to select the test cases that cover almost as many cases as we can with the minimum number of cases. This is still a very interesting research topic, but on the other hand, it emphasize the importance of testing with all its levels.
For the development team we agreed to test every piece of software using unit test. The cycle we agreed on was as follows: Green - Red - Green.
The first Green is when we first write the function definition, with its testing that is asserting True.
The red comes when the test cases is written for the function that was not yet implemented. The last Green is when the function implementation is done. And so on.
This was really helpful in changing the way we as developers look at the software. It increased our criticism and made us understand the requirements more deeply. This applies on the small tiny methods where we applied unit testing, and on the behavior of the complete feature when we applied the BDD - Behavior Driven Development - using Cucumber Gherkin.

3. Working Agreements

As the fist agreement said - we work with agreements - we extended the basic agreements to include the following:

1. Definition of done and ready.
2. Pairing.
3. Start and end times / critical hours.

1. Done and Ready

These agreements - after a short period of time - have become part of the team DNA.  The first one is about integrating with the business and quality teams. We agreed on defining the ready feature as those which Gherkin files are ready for!. In other words, the ready feature are the features which are described in detail in Gherkin file that contains different scenarios that describe the usage of the feature and how the system shall respond in these scenarios. While a feature is marked as done if and only if it passes all the unit and behavior testing at the development side, and pass by the testing done by the quality team and accepted by the business team. These 3 conditions has to be met in order for a feature to be completed.

2. Pair Programming

In 1999, Kent Beck published the new software process Extreme Programming in which he introduced the term pair programming. Two years later when the Agile Manifesto has been published, Professor Laurie Williams from the North Carolina State University has introduced a practical application of pair programming in the 14th Conference on Software Engineering Education and Training. Pair Programming was considered as new method of programming team working together where two developers share work together on the same workstation. One of them is the observer who is watching and monitoring the code being written, and the second is the navigator who actually writes the code. Both developers switch the roles every while. 

I can say that after applying this, the quality and standardization of the code has drastically increased and without a code review. Pairs review code of each other and brainstorm together to find the optimum solutions for the problem they are trying to solve. In the beginning I thought this was going to slow the delivery time at least by 50% as instead of having N developers working on N problems, now we have N developers working on N/2 problems! but the output was exactly the inverse of this hypothesis. The delivery time was reduced to almost the half and quality has tremendously increased.

In addition to this, now we have everyone working in everything! the front end guys are making web services and data models, while the back end guys can easily make an animated graphical representation in an HTML page.

3. Critical Hours

The term Flextime was invented in the early 70s, by the entrepreneur Wilhelm Haller. Flextime offered a different option instead of the standard working hours from 9-5, where as employees have the flexibility to work in a flexible hours fulfilling the critical hours which are 3 to 4 hours a day.  We've considered this in our agreements by setting the critical hours and afterwords we announced this to the top management :)

Uptill the time this article was written, and after more than 6 month, the team work is flowing. Not as it started, and the agreements changed many many times, but eventually they are still agreements. The team was and still a single unit as it always has been ever since.