The Next Generation of Release Management is for Everyone

It doesn't really matter if you're using a traditional or agile methodology.  Release management must start at the start of your release cycle, not at the end of the development cycle.  And proper release management will benefit the entire team through the entire lifecycle.

Managing a Release
Taking a look at some of the issues that need to be dealt with as part of release management, it becomes clear that release management is an end-to-end lifecycle management process.

1. What's going into the release?
2. What are the priorities in case we run into time/resource trouble?
3. How flexible is our process with regard to changing the release target functionality?
4. Which outstanding problems from the previous release need to be addressed?
5. How is the release to be managed to minimize risk and ensure success?
6. What level of verification is necessary and what is that plan to ensure full coverage?
7. Which tool(s) are going to be used to support the release?
8. When and how will we commit a release date to marketing?
9. How do we track our progress against our release plan?
10. How will we generate and deploy/distribute the release artifacts?
11. How do we identify, for the customer, exactly what actually went into a release?
12. How will we track and improve release quality after the release?

Process is critical, but it's equally important to have the tools in place that allow the capture of all release information, and the query of this same information in a manner that helps the team make critical decisions in an efficient manner.  Process must be clearly (and easily) understood by all of the players.  Tools must be easily used by all the players, including all levels of management.

Capturing Release Information
When it comes down to it, tools provide the critical capability to capture release information.  It's not sufficient to identify pieces of data.  Each piece of data must be clearly linked to its place in the release puzzle.  Whether it's a new or modified line of code, the success or failure of a test case, or an internally raised problem report, it must be easy to navigate backwards and forwards through the process lifecycle to identify the impact on and resulting from the piece of data.

When it comes to selecting and using appropriate tools, I always recommend a complete ALM solution - not one sewn together by the CM team.  If the data does not reside in a single repository, the data capture will be more difficult, and the query and traceability even moreso.  Regardless, a next generation tool will address two critical functions:

(1) Pick up data from a user's context
(2) Provide a user interface that allows for automation of traceability capture.

Looking at the first function, it must be easy to specify a user's context in a clear, unambiguous manner.  This may be as simple as telling the tool environment "I'm working on the build that customer XYZ has" or "I'm working on the codeline for release 2 of product ABC".  Generally, and most often, it doesn't have to be more complex than that.

Now when I create a new change, the data is automatically populated with the product and release I'm working on - no finger problems.  When I raise a problem report, it is stamped with the product, release, creator/originator, date and time.  No need to fill in any of these details manually.  When I check out a file, perhaps the tool can even let me know if I need to branch (instead of leaving this to a branching