What is Release Management?
Release Management is the activity of defining and coordinating how one of the Releases identified in the Product Plan will be implemented.
What is a Release?
In Agile terms, a release is a fixed period (a ‘timebox’) within which an agreed scope of work (stories) will be delivered. It may consist of an upgrade to a single product or a selection of priority stories from various sources. Usually in Agile, a release is divided into still shorter timeboxes (iterations), and may include implementations by more than one team working in parallel.
Individual releases are identified and scheduled in the Product Plan.
Release or project?
Agile usually divides work into ‘releases’. This term suggests that development consists of a succession of similar efforts, all connected to the same product. That is often valid, but many organisations also use Agile as a project delivery process too – that is, also for distinct packages of work, but in this case each has its own unique goals and approach, and is not explicitly connected with other work.
- As the PMI define it, a project is:
- aimed at a singular goal.
- staffed by people from areas that don’t normally work together.
- A standard Agile release, by contrast:
- is generally part of a permanent product-based programme of work.
- aims to work in a similar way to the same team’s other releases.
- often aims at an outcome much like other releases (i.e., another update of the same product).
- should be staffed by team that, if at all possible, have all the experience and authority needed to carry out the work.
Fortunately this has little effect on how Agile works, so in Agile201 only the more ‘Agile’ term ‘release’ is used. But the differences shouldn’t have any effect on how you use Agile201 – if you are a project-based organisation, just treat ‘project’ and ‘release’ as the same.
What is Release Management?
The Release Management cycle is the process through which the Agile team details the individual releases identified in the Product Plan. It turns the release’s why (the release’ purpose) and what (the backlog items initially assigned to the individual release) into a who (the iteration teams) and then the when (the iteration schedule) and the how (the iteration backlogs).
Release Management spans all the tasks needed to implement the Product Plan. These are:
|Create the Release Charter.||The Release Charter is the foundational document of the release. It defines (at the level of the Release as a whole):|
|Plan the Release.|
|Conduct Iteration 0.||Iteration 0 (‘Iteration Zero’) ensures that the team are fully prepared to begin work on a release. It is designed:|
After that, all that remains to be done is to plan and execute the iterations identified in the Release Plan.
These tasks are described in more detail below.
The key Release Management tasks
Release Management can be divided into a small number of simple tasks.
Create the Release Charter
Click here for the structure and composition of the Release Charter.
Click here for the process of creating a Release Charter.
Plan the release
Depending on the complexity and scope of the release, it may involve one or more teams, each carrying out one or more iterations. It will also usually include an Iteration 0 for preparations. So even a high-level Release Plan may be complicated (though in this example there is only a single, release-end deployment):
Release Planning in the Agile lifecycle
As the diagram below shows, Release Planning begins early in the Agile lifecycle as a whole. This is not the only point at which the release is planned – releases are open to change and rescoping at any time, and so maintaining the Release Plan is a constant process.
The Release Planning process
Overall, this is what Release Planning looks like:
On the other hand, the Release Plan does not need to define the details of individual iterations, so its complexity is limited. As the Release Plan is produced jointly with the Iteration Leads whose teams will be accountable for delivery, it can be expected that the Release Plan will be realistic.
For a step-by-step instructions for Release Planning, see here.
Prepare the Release Backlog
The initial scope of each release is set by the Product Plan. However, as the actual release approaches, it should be expected that the original scope will be reviewed and refined.
No matter what its scope, the Release Backlog should contain only stories that:
Preparing the Release Backlog should also include checking that it is still credible to deliver that number of stories in the timebox available.
What’s the right format for a Release Plan?
What should the Release Plan look like? A simple table of iteration start and end dates is often perfectly adequate, but a ‘roadmap’ can also be helpful, showing:
- The destination (i.e., the final release date, if it is a single event).
- The major milestones (typically external events such as seasonal dates).
- The ‘road’ each team will take (e.g., swimlanes showing the sequence in which items will be completed, new platforms supported, etc.).
- Intersections between different ‘roads’ (e.g., integrations between neighbouring teams).
- The overall timeline.
But like the Product Strategy, the Product Plan should be no more detailed than is strictly necessary, and should be presented in whatever minimal format is needed to communicate with its audience. A detailed Gantt chart is unlikely to be needed.
How is the Release Plan validated?
Before the Release Plan is finalised, it should be subjected to a two-way validation:
- If we implement all the work items identified in the Release Backlog, will we have covered the scope set for the release in the Release Charter and Product Plan?
- Including implementing all stories assigned to this release?
- And equally importantly, will we have achieved the release’s goals?
- Can we trace all the work items in the current Release Backlog to some aspect of the release’s purpose and scope?
As with Product Planning, without full traceability in both directions, there’s a serious risk that the team’s work will become divorced from the release’s purpose and goals. If that happens, no matter how good a product the team builds, from the organisation’s point of view it will have failed.
More detailed validation criteria are given in the Release Planning practice.
Once the Release Plan is in place, the team begins preparing for the release work. This is done during Iteration 0. This includes tasks such as agreeing a design approach and a test strategy, setting up tools, data and environments, special training, and so on.
Click for more on Iteration 0.
More complex models of Release
As ever, there are complications to any basic model of Release Management.
Scaling Release Management
Release Management isn’t a ‘one-size-fits-all’ activity:
- In small organisations or service functions whose main work consists of responding to small customer or stakeholder requests, Release Management may be limited to managing the backlog.
- In a large, complex organisation, Release Management is an equally large, complex topic, largely concerned with how multiple teams can collaborate and deliver across multiple parallel sequences of iterations.
Especially when releases are long and complex, some Agile teams include a special ‘hardening’ iteration at the end of the release. Although there is a case for this practice, it should be used sparingly and only for very clear reasons.
See here for an extended discussion of hardening iterations.
The release may not actually release anything – or at least, not directly to users or customers. All organisations have their own complicated scheduling issues, and a release may only deliver working software (more precisely, in this case, potentially working software) into a staging area, perhaps for integration with other components, pending other organisational changes, awaiting some seasonal event (the holiday season, perhaps), and so on.
It is not unusual for Releases to start before the previous release is complete, creating a continuous cascade of overlapping work in which the delivery of successive releases occurs at one pace – say, every two weeks – but the development of each release may take longer – say, four weeks. This would require each release to begin before the previous Release is finished – as illustrated in the diagram.
This model also allows releases to be of different lengths, even though the cadence of deployment remains fully consistent. This can be useful, although it does tend to disrupt the ideal of a sustainable pace of work.
How does the Agile team use the Release Plan?
The Release Plan is a living document.
It should both be a continued point of reference for the release team and continually maintained to reflect changes.
Using the Release Plan to think ahead
By showing how the release will unfold through its various iterations, the Release Plan encourages the team to visualise their future work in more concrete terms, to think about the flow of work as a whole, and to ask questions like:
- What are the delivery events and their dates?
- What do we need to achieve at each point to make this happen?
- What difference does the sequence of work make to how we develop?
- Have we allowed enough effort to deal with technical issues such as architecture and technical debt?
- Are all the team fully engaged throughout the release?
- Can we realistically maintain the expected cadence of development? If not, what do we need to do about it? Challenge the Release Plan? Or change the way we work?
Knowing the answers to questions like this will make it much easier for the team to anticipate change and avoid making bad, short-term decisions. Conversely, with this kind of insight, what might have been no more than a series of uncoordinated tasks can be turned into a smooth, well-structured release.
How do you display the Release Plan?
So now that they have a Release Plan, what should the team do with it?
The most basic thing the team can – and should – do is to blow it up and hang it on the wall where the team – and visitors – can see it every day. With the Release Plan constantly in the corner of their eye – ideally right next to the Product Plan – the team will continue to think about what they are trying to achieve.
It will also inspire them in a dozen small ways to think about how their own work can be adapted to suit the Plan better.