CM: THE NEXT GENERATION of Release Management

Planning and Tracking the  Release

Release Management starts with identification of what is being developed for a release. You may have an Agile development team or a more traditional model. Either way, you need to plan what's going into your releases. The individual features or problem fixes must be identified and tracked, that is, linked to the requirements/requests which
were responsible for them, and referenced from the changes that implement them.

With Agile development, your planning is in the form of identification of features/problems and prioritization of these. Every week or two, you re-visit your to-do lists and adjust priorities. Your Agile development is trying to keep your development team focused for the next couple of weeks. Your release management is dealing with what you're going to release 3 to 12 months from now, and in the releases that follow.

For successful release management, your efforts must carefully be traced to the features that are completed, and last minute specification changes, typical in a fast-feedback agile iteration, must be adequately captured along the way.     In the end, you will have a product, but you need to know what is in the product and what is not.   If your ALM tools don't allow you to accurately track this along the way, you're agile gains will be lost to additional delays and inaccuracies in your release process.   If the ALM tools are intrusive, they'll interfere with your lean operation.

In a more traditional schedule-based development environment, release planning is done as part of the requirements specification effort. Requirements are identified and ranked by priority/weight.   As the customer requirements are turned into a Functional, an initial feature-by-feature effort estimate allows you to plan your time frames.   Here again, as the plan is executed, it's critical that the actual development changes reference the features and problems being addressed.   Your CM/ALM tools along with your peer review process, can ensure that this happens.

One Release per Customer?

Early on in a product's lifetime, there's a tendency to customize each release to a specific customer's requirements.   This is a good thing, not a bad thing.   But if it's not handled properly, as I've seen time and time again, you end up managing multiple releases, one per customer, instead of managing your product.

It's important to recognize that the development team and the product design are crucial release management factors.   Customization of releases is always going to give you a competitive edge. However, the goal is to customize at the customer's site, not in the development shop.   If your developers are creating custom builds
for your customers, you will rapidly discover that your resource requirements grow linearly with the number of customers you have, and that your product complexity grows exponentially.

The development team will invariably have some experience on board.   Explain
to them the requirement that customizations will need to be done post-delivery
- at the customer's site.   There is actually a whole range of customization capabilities that will need to be delivered.   Some need to be done prior to
delivery.  For example, platform-specific builds must be created before delivery. The development team needs to be in the habit of identifying which customizations can be held off as late as possible, and designing the software that way.   Consider whether the customization is:

• a coding time customization
  

• a build-time customization

• an installation-time
  customization

• an initialization-time
  customization

• a run-time customization

Your team must have the goal of  moving customizations as far down the chain as possible.   Each level you are able to move down the  chain will save you significantly on your build and release administration and  complexity.  Eager programmers might say  that they have a nifty way of managing conditional compilations to put the  right combination of features in place.