April 05, 2007
The Agile End Game
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:
- 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:
- 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.
|
Previous Page |
1 The Agile End Game
|
2 Final Testing
|
3 Release Iteration(s)?
