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:
- You need to train large numbers of users, but have a limited number of training resources.
- You have different release dates for different parts of the world because you need to wait for translation of your system.
- A "big bang release" of the system is deemed too risky.
- You have different groups of stakeholders, each of which work on different business cycles.
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: