And now for something completely different. Agile software developers love to talk about the construction aspects of software development, but rarely do we discuss the other, "uncool" issues faced by IT departments. These include project issues such as initiation and release, and enterprise issues such as governance, enterprise architecture, portfolio management, and operations. It is of little use being really good at building software if you can't manage projects effectively or run them once they are in production. This month, I discuss the release-related activities that occur at the end of a development project.
Figure 1 depicts a generic lifecycle for agile software projects. As you can see, there are several different types of iterations, or as Gary Evans would say, "seasons of a project." One important aspect of the lifecycle is the release iteration, also referred to as the transition phase in the Open Unified Process (OpenUP), the release sprint in Scrum, or the end game in the Eclipse Way. The goal of the release iteration(s) is to successfully deploy your system into production. For complex projects, you may require several release iterations (more on this later).
There are several ways to enter the end game of an agile project. Ideally, you do so because it makes sense, which occurs when you've built sufficient functionality for your stakeholders and your defect rate is down to an acceptable level. A common practice on Scrum teams is to create a "burn down chart," which tracks the number of requirements still left on the requirements stack. However, in practice, I've found them to be more effort than they're worth unless they're automatically generated for you by your toolset. Value is in the eye of the beholder, and because stakeholders actively participate on agile projects, it's usually straightforward for them to identify when they've achieved sufficient new functionality since the last release of the system. Your defect rate can easily be calculated by counting the number of defect stories generated by your investigative testing efforts (see my column "Agile Testing Strategies," January 2007).
There are two other common ways to enter the end game, both of which can be spectacularly bad experiences if you haven't met the previously described criteria. One motivation to release your system in production is simply because you're scheduled to do so, often for contractual or regulatory reasons. I would rather ship a solid product a few months late than ship an inadequate and/or buggy system on time. Another potentially problematic motivation to release your system is because your stakeholders have stopped funding your project and want you to ship what you've got done. Because agile teams produce "production ready" code each iteration, they are more likely than traditional teams to be able to actually deliver something of value in this situation, but it's rarely a pleasant situation to find yourself in.
