Channels ▼


The Agile End Game

Scott is a DDJ Senior Contributing Editor and author of numerous IT books. He can be contacted at

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).

[Click image to view at full size]

Figure 1: The agile software development lifecycle.

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.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.