Boost Your Organizational Agility With Test-First Pair Development
Boost Your Organizational Agility With Test-First Pair Development
Never too much of a good thing. Take a look at what happens when you combine Test-Driven Development and Pair Programming.
Join the DZone community and get the full member experience.Join For Free
Agile software development methodology is the key selling point for many IT organizations, however many of the organizations have gone by the literal meaning of the word "Agile." They follow Agile practices without really being Agile. If we reference the Agile Manifesto for Agile Software Development, it focuses more on the human factor (people, interaction, collaboration) to produce working software, rather than on processes, tools and strict planning. As described in the book Agile IT Organization Design, organization culture plays a key role in an organization becoming true Agile organization. Agile culture is based more around collaboration and cultivation than a controlling and competence culture. This post describes how the test first paired development can boost organization agility and culture.
The Test-First Pair Development
When a pair of experts think about how a function will be used before developing the function, that is test-first development. Extreme Programming Explained: Embrace Change talks a lot about Test-Driven Development (TDD), pair programming, tools, principles, and practices. The term test-first pair development comes from TDD and Pair Programming, but it is not restricted only to developers but is also applicable to other software development roles (BA, QA, TL, TA, etc).
Here are the key concepts :
- 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 the next test fails and then perform step 2. Keep doing this until you reach a 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 the above steps again to improvise the feedback.
- Pair sign up — Two people sign up for one outcome.
- Pair rotation — Pair should be rotated on an interval.
- Collaboration — Pair must work together. One person is reviewing, while the other is doing the task, and then they exchange their position when needed.
- The development environment and seating should be such that both can work together.
- Pair with diversity — Make a pair of diversity in terms of role, experience, and skills, so that everyone learns from each other. For example, pair with QA to write automated acceptance tests, or pair with an infrastructure expert to fix DevOps issues.
Combining Test-First and Pair Programming
- One person thinks of and writes a test and the other person implements the functionality needed to just pass the test.
- Another person thinks of and writes 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
The following are 5 major benefits for an organization using this approach.
1. Fail Early
We get feedback early in the development lifecycle. The artifact we produce is getting reviewed at the very first stage of development in two ways. First, it is getting tested by the test artifacts and second, it is getting reviewed by a peer as and when it is written. It will produce better quality software. As described in the test pyramid, we build an organization practice to strengthen the base to the testing pyramid.
It is not just in terms of product feedback, but we also get feedback on people for alignment towards Agile.
2. People and Interaction
Test-first pair development needs a great interaction between the pair, and gives equal opportunity to each one. The 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 expects support from others, he/she needs to support others. In such a team, people build trust and respect among other. It promotes collaboration culture in organization, which is the key for any real Agile organization.
3. Outcome-Oriented Teams
Test-first pair development works well with outcome-oriented teams, where people can cross pair (pair across roles) to achieve the desired outcome efficiently. When people cross pair, they understand each other's pain, and better work for each other's success, eventually leading to the better business outcome. Test-first methodology promotes building software to fulfill the immediate business need, and avoid building unnecessary source code.
4. Change with Confidence and Satisfaction
In a traditional way, it is always a feared event when changing any existing code, we never know what will break, and sometimes 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 the team, and are more focused.
5. Overall Cost-Effectiveness
People feel that pair development takes more effort than the traditional development, as two people are assigned to a task which can be done by one person. It is not true for most of the cases due to the following reasons:
- Quick on-boarding — Paired development doesn't need a huge on-boarding cycle; the new joiner can start contributing from the day one and will learn on the job, while working with the pair. It is the pair's responsibility to make the newcomer comfortable.
- No lengthy review cycle — We don't need a special review cycle for the code. Almost 10% of the implementation effort is assumed for reviews which is being saved.
- Less defect rework — Since we get feedback well early, we can fix the issues as and when they are 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 a good amount here.
- Less testing effort — Test first approach promotes more automation tests, and tries to maintain the test pyramid, thus creating less effort for testing.
- Effectiveness — There is less waste at various levels, and the team is focused on the delivering the right business requirements at tbe right time in iterations. Inefficiencies can be removed early based on the feedback at various levels.
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 organization.
Opinions expressed by DZone contributors are their own.