In his CM: the Next Generation series, Joe Farah gives us a glimpse into the trends that CM experts will need to tackle and master based upon industry trends and future technology challenges.
Planning and Tracking the Release
Release management begins with the 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. They must be linked to the requirements and requests that were responsible for them, and then referenced from the changes that implement them.
With Agile development, planning is in the form of identification of features/problems and prioritization of these. Every week or two, revisit 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 deals with what will be released 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. 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 is a tendency to customize each release to a specific customer's requirements. This is a good 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 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. Additionally, 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 an entire range of customization capabilities that will need to be delivered. Some will 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