The Agile End Game

Release-related activities that occur at the end of a development project should be the first thing on your mind.


April 05, 2007
URL:http://www.drdobbs.com/architecture-and-design/the-agile-end-game/198800565

Scott is a DDJ Senior Contributing Editor and author of numerous IT books. He can be contacted at www.ambysoft.com/scottAmbler.html.


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.

Final Testing

Repeat after me: The release iteration is not a testing phase. The release iteration is not a testing phase. The release iteration is not a testing phase. The majority of testing occurs throughout the project in the form of confirmatory testing performed by the development team itself, or investigative testing performed by independent testers to catch any pernicious bugs that slip through the cracks (again see "Agile Testing Strategies," January 2007). Having said that, as indicated in Figure 2, you will still do some testing during the release iteration.

Although "agile acceptance testing," also known as "customer testing," is a part of the confirmatory testing efforts that occur throughout a project, you may still need to perform a final release acceptance testing effort where people outside of the team are involved. Testing of your installation/deployment scripts is particularly important during the release iteration because you don't want any surprises when you actually try to deploy.

Don't get me wrong, the activities that I've described as release testing in Figure 2 can and should be done much earlier in the lifecycle. My point is that these forms of testing are particularly pertinent during the release iteration to assure your stakeholders that your system is truly ready for deployment. Many organizations require that a system be put through some sort of formal sign-off process before deployment regardless of the development paradigm. The good news is that the increased focus on quality and testing by agile teams streamlines this effort.

[Click image to view at full size]

Figure 2: Testing during the release iteration.

More Than You Think to Releasing a System

The common rhetoric within the agile community is that our software is always "production ready" because we deliver tested, working software at the end of each construction iteration. This is a good thing, and for simple systems, you might be able to simply copy the software onto a production server and declare success. In more complicated situations, you may need to:

  • Hold acceptance reviews with stakeholders.
  • Finalize relevant documentation.
  • Translate the UI and supporting documentation into other languages.
  • Finalize and validate testing efforts.
  • Create physical collateral, such as manuals and installation media, for disbursement to end users and your operations and support (O&S) staff.
  • Ship physical collateral and hardware.
  • Replace and/or install physical assets, including workstations, servers, and network components.
  • Replace existing software with new versions.
  • Update existing databases, including any relevant data migration and/or database schema changes.
  • Update any O&S test environments used to simulate production problems.
  • Train end users and O&S staff.
  • Run the existing system in parallel with the new release during a defined transition period.
  • Fix any discrepancies discovered during the transition period.
  • Train the team that is taking over maintenance and evolution of the system.

Release Iteration(s)?

The release iteration is often the perfect time to finalize your documentation. As I described in "Agile Documentation Strategies" (March 2007), you want to wait until information has stabilized before you invest time putting it down on paper. The whiteboard sketches that overview the high-level requirements supported by your system, and the technical architecture of it, might now be recorded using more sophisticated drawing tools to form part of your system overview documentation. Any operations and system (O&S) manuals, as well as end-user documentation for this release, must also be finished. Hopefully, the majority of it was written during later construction iterations as you neared the release iteration; otherwise, you may find that your single release iteration has now expanded to several iterations.

Due to their complexity, some systems will require several iterations prior to release. Common reasons to stage your system release in multiple iterations include:

The end game of a project can be a difficult endeavor, one that shouldn't be underestimated. A valuable resource pertaining to the release iteration is The Unified Process Transition and Production Phases (CMP Books, 2001). Edited by Larry Constantine and myself, the book includes articles by Cem Kaner, Norm Kerth, Karl Wiegers, Steve Adolph, Martin Fowler, and Jim Highsmith.

Release Planning "Don't Forgets"

Successful releases, particularly for complex projects, are planned almost from the very beginning of a project. The following are issues you want to consider long before you get to the release iteration:

  • Involve operations and support (O&S) departments early in the project. O&S people are critical stakeholders, so you want to understand their requirements and how to work with them effectively.
  • Identify the legal and/or regulatory compliancy issues. Food and Drug Administration (FDA) guidelines or the Sarbanes-Oxley (SOX) act may be applicable to your system, increasing the required levels of documentation and internal auditing.
  • Identify potential release windows. Your operations department may have strict rules as to when a system may or may not be released, and you may need to compete for a slot within their overall release schedule (your system is just one of many).
  • Identify anyone who must sign off that the system is ready for deployment. This includes end-user management, internal audit groups, and O&S management.
  • Identify any marketing or communication planning needs. For commercial software, you clearly want to market it well in advance of the actual release. For internal systems, which will have a large effect on end users, you may want to describe the coming changes well in advance.
  • Identify any dependencies with other systems. You may need to coordinate the release of your system with the release of several other systems; sometimes, a little bit of initial architecture modeling early in the lifecycle can go a long way towards avoiding problems later in a project.

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.