One of the questions I hear a lot from Agile teams is “how can we have a stable build to test stories as they are completed?” Often, the only time the build is stable is towards the end of the iteration. That then squeezes the QA folks or sometimes even has them testing the previous iteration’s stories in the current iteration. Hmm. That sounds a bit like our old friend Waterfall.
Usually, when the question is asked, the team is creating and automating unit tests and doing continuous integration. That’s not the issue. (If you are not doing those things, stop everything and implement these three practices immediately!) But let’s assume for the moment that you are doing these three practices.
The problem is getting a build which consists of only stories that are considered “complete,” but still need a bit more work done on them, such as exploratory testing, load testing, usability testing, demo for customer feedback, etc. You might say, “but you can’t do that until the end of the iteration.” Ok, but then you are back to the problem of a compressed QA cycle and having development either sit on their hands or move on to the next iteration, neither of which represent Agile thinking.
There’s a simple solution to this problem, which you may have “thrown out with the bath water.” Branches! Or, in AccuRev parlance, streams (though I’ll stick with branches for simplicity). Each process stage gets its own branch. That doesn’t mean that you can’t write code and tests at the same time, only that code can’t advance to the next branch until it meets the criteria of that branch, such as “coding is done” and “all tests are written and passing.” I know, you cringe at the thought of branching and merging, but that’s probably because you are thinking of branches that contain long-lived changes. We’re not going to do that here.
The idea presented here is to advance changes through the set of branches as quickly as is practical. As changes get propagated to each branch, CI is done against that branch. If it succeeds, it gets promoted to the next branch. If it does not succeed, then that developer (possibly with help from her teammates) fixes the branch. This is similar to how stopping the line works in a modern lean manufacturing facility.
In AccuRev, this process is greatly simplified. You can create a set of streams instead of branches, and streams can model your exact process. Promoting work from stream to stream is a simple drag and drop operation.
In the diagram above, there are streams for each of the stages from “wip” to “done.” Since each stage is a stream, you can run continuous integration at each stage. You can also do builds, for instance from the “tested” and “done” streams to do things like exploratory testing. By definition, a build from the “done” stream only contains changes which are built; integrated together; have unit and other tests written, automated and passing; and whatever other criteria you have for “done.”
