Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Design

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.


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.