Agile software development methodology is the key selling point for most of the IT organisations, however many of the organisations have gone by the literal meaning of the word “Agile”. They follow agile practices without really being agile. If we go by Manifesto for Agile Software Development, it focus more on human factor (people, interaction, collaboration) which produces working software as per the need of time, than on processes, tools and strict planning. As described in the book Agile IT Organization Design, organisation culture plays key role in the in becoming true agile organisation. Agile culture is more around collaboration and cultivation than a controlling and competence culture. This post describe, how the test first paired development can boost organisation agility and culture. This article is also my takeaways from the book.

The Test First Pair Development:

When a pair of experts think about, how a function will be used before developing the function, is the test first development. The book ‘Extreme programming explained: embrace change’ [3] talks a lot about TDD(Test Driven Development), pair programming, tools, principles and practices. The term test first pair development is generalised from TDD and Pair Programming, however it is not restricted only to developers but also applicable to other software development roles (BA, QA, TL, TA, etc) and cross roles.

Following are the key concepts :

Test First Development

• First-Fail-Test : Think of a very basic test for a business functionality that you want to implement. Implement/define the test first.
• Just-Pass-Test : Write code/artifact which is necessary to pass the test. Don’t write unnecessary code to satisfy your assumptions and intuition.
• Next-Fail-Test : Keep writing test until next fail test and then perform step 2. Keep doing this until you reach at just sufficient outcome.
• Refactor/beautify the code/artifact and make sure all tests are passing. Do it in between 2 and 3.
• Get the outcome reviewed, collect feedback and follow above steps again to improvise the feedback.

Pair Development:

• Pair sign up - Two person sign up for one outcome.
• Pair rotation - Pair should be rotated on an interval.
• Collaboration - Pair must work together. One person is reviewing, while other is doing the task, and then exchange their position when needed.
• Development environment and seating should be such that both can work together.
• Pair with diversity - Make a pair of diverse personality in term of role, experience and skills, so that everyone learn from each other and respect. eg : Pair with QA to write automated acceptance tests, Pair with Infra Expert to fix DevOps issues.

Combining Together:

Pair follows the test first development practice for example :

One person think and write of a test and other person implement the functionality needed to just pass the test. Other person think and write the next test and the first one will implement the functionality to make it pass. Pair with QA/Tester/PO during development to review the outcome before releasing it to QA.

Benefits of Test First Pair Development:

Following are 5 major boosts for organisation for using the approach.

1. Fail Early

We get feedback well early in the development life cycle. The artifact we produce is getting reviewed at very first place of development in two ways. First, it is getting tested by the test artifacts and second, it is getting reviewed by peer as and when it is written. So it will produce batter quality software. As described in test pyramid [4], we build an organisation practice to strengthen the base to testing pyramid.

It is not just in term of product feedback but also we get feedback on people for alignment towards agile.

2. People and Interaction

Test first pair development need a great interaction between the pair, and gives equal opportunity to each one. Pair gets rotated after some time, which helps in building the team bonding. People start believing in the word “Team” and understand that if one expect support from other then, he/she need to support others. In such a team, people build trust and respect among other. It promotes collaboration culture in organisation, which is the key for any real agile organisation.

3. Outcome Oriented Teams

Test first pair development works well with outcome oriented team, where people can cross pair (pair across roles) to achieve desired outcome efficiently. When people cross pair, the understand each other’s pain, and better work for each other’s success, eventually lead to better business outcome. Test first methodology promote to build software to fulfil immediate business need, and avoid building unnecessary source code.

4. Change with Confidence and Satisfaction

In traditional way, it is always a feared delivery when changing any existing code, we never know what will break, and sometime we get the feedback from the end user. But here, people are more confident in making changes in the existing code which is well covered by the tests. We get immediate feedback by the failing tests, if all existing tests are working then we are good to go, with passing tests for changed functionality. Another eye is always there to watch you. With this approach, people are more satisfied with what they are doing, as they are more interacting, getting more support from team, and are more focused.

5. Overall cost effectiveness

People feel that pair development is a double effort then the traditional development, as two person are assigned to a task which can be done by one person. It is not true for most of the cases due to following reasons:

• Quick on-boarding - Paired development don’t need huge on-boarding cycle, new joiner can start contributing from the day one and will learn on the job, while working with the pair. It is pair’s responsibility to make the new comer comfortable, it is for his own advantage.
• No lengthy review cycle - We don’t need special review cycle for the code. Almost 10% of implementation effort is assumed for reviews which is be saved.
• Less defect rework - Since we get feedback well early, so we can fix the issues as and when they found. Rework is proportional to defect age ( defect detected date - defect induced date). Around 20% overall effort is assumed for defect fixes rework. we may save good amount here.
• Less testing effort - Test first approach promote more of automation tests, and tries to maintain the test pyramid, thus lessor effort for testing
• Effectiveness - There are less wastage at various level, team is focus on the delivering right business requirement at right time in iterations, inefficiencies can be removed well early based on the feedback at various levels.

Conclusion

We have discussed the test first pair development methodology, which is about marrying TDD and Pair Programming. We described key concepts of the test first and the pair programming, and then we described the key benefits to the organisation.

References :

[1] - http://agilemanifesto.org/

[2] - https://info.thoughtworks.com/PS-15-Q1-Agile-IT-Organization-Design-Sriram-Narayan_Staging.html

[3] http://ptgmedia.pearsoncmg.com/images/9780321278654/samplepages/9780321278654.pdf

[4] https://martinfowler.com/articles/practical-test-pyramid.html

This article was originally published on My LinkedIn Profile