by Bill Rinko-Gay
One of the advantages of Agile is the ability to deliver continuous improvements to your customer. If you have experience in traditional development paradigms you a release is usually a mixed bag filled with new functionality and new (and sometimes old) defects. This is frustrating for users and the development team. You seem to always be under a backlog of bugs that keeps the software from delivering all the business value you intended.
This constant backlog doesn’t just occur in traditional development, it can occur on Agile projects as well. The hurry to try to reduce the backlog by fixing last-minute bugs leads to thrash, and thrash can lead to reduced quality as hurry cause the team to introduce new bugs. Your goal is to move always forward with your code, but the reality is often “two steps forward, one step back.”
One way to avoid this problem is to think through the activities as a single phase: “dev-test.” When the work is ready to start on an iteration the developers and testers map out how the software is going to be changed. The team should plan to bundle stories into builds. The build strategy should maximize the team’s efficiency while delivering continuously increasing functionality at high quality. The more compact the changes between builds, the easier it is to verify those changes are made correctly. Unfortunately, this isn’t easy. Making this possible sometimes requires extra work. Still, the payoff is worth the effort.
As a specific example, suppose all the stories in a particular iteration require a new save functionality. Also, suppose the save functionality should be written last because developers need to see the other stories’ implementation before writing the save function. Rather than delivering all the functionality at once, the developers could write a temporary save function that would allow the early stories to be tested. This is “wasted” work for the developers, but it increases the efficiency of the team because they can get fast feedback on the early stories and get any defects fixed before the real save function is implemented. If the other stories are tested complete, then problems caused by the save function are isolated. Achieving these goals would not be possible without developers accepting a little less efficiency.
Similarly, suppose the GUI changes are the least risk for introducing bugs, leading the team to agree to write the GUI last. This means the testers will need to re-visit all the GUI functionality after testing the other stories. If the GUI stories had been written first, the testers would not have to repeat tests at the end to exercise those GUI functions, but the developers would not get fast failure on more risk-prone stories. In this case testers agree to a less efficient test plan to improve the efficiency of the developers.
The advantage of doing multiple releases with small increments of functionality is the reduced time to test each incremental build leading to higher overall quality. Development and test are both more efficient, and the customer is much happier.