An Agile Approach to Release Management

Agile teams work under the same constraints as other software development teams, having to address issues of maintenance and support, the need for external artifacts like documentation and training, and the reality that not every customer can accept change at the rate that an agile team can (in theory) deliver it. To attain the goal of a shippable product at the end of every iteration, an agile team must manage the flow of change from a customer, and maintain high discipline and  good engineering practices.

In the paragraphs below we will discuss how release management works in an agile project, and explain how even non-agile teams can benefit from applying aspects of an agile approach so that you can deliver value to your customers in a more predictable fashion.

Agile Principles

Agile Project Management Practices enable you to manage schedule risk in a project. In a sense, many are simply good practice:

• Plan to work in time boxed iterations of 2-4 weeks
• Maintain a  backlog of feature requests in prioritized order,  and revisit the priority at each iteration boundary
• At the start of an iteration select the highest value items from the backlog. Do detailed planning  for these items.
• Integrate Often

• Verify Often
• Deliver and review against a plan.

These practices affect how you think about release management because release
management is a planning activity and any planning activity has uncertainty which increases the further away you are from the present. The goal of having features complete or not complete at the end of an iteration allows you to determine have a clear idea of what will be available to ship. The prioritization of the backlog allows you to compensate for problems by having the most important features developed first, so that you can still meet a release date should that matter for market or regulatory reasons. The "always shippable" goal means that you can, if need be, accelerate your release schedule.

An agile approach enables better release planning by combining planning discipline, which helps you to focus on the highest value work, and engineering (including SCM) discipline, which helps you to identify and fix problems early, giving you more predictability. Agile practices make shipping a release a decision that the product owners can make without worrying if the team will meet a date far in the future. The role of the agile team is to enable allow the product owner to make the decision on short notice if need be.

Realities

The IT Process Institute's report Change Configuration and Release Performance Study says that:

• Release trumps change - rigorous release build, testing and rollback practices have broad impact on individual performance measures and overall performance. Change tracking and change oversight practices are necessary but not sufficient to achieve performance improvement on their own.
• Process discipline matters - there are no change, configuration and release silver bullets. Building a process-focused culture and monitoring and responding to process exceptions predicts top-levels of performance more than the many of the industry recognized best practices in these areas.

This is very much in line with an agile approach to software development.

While the focus of much of the literature on agile methods is about single codeline development, 'Release Management' often refers not merely to managing a single release, but to the overall discipline and methods of managing multiple releases at the same time. There are all sorts of valid business reasons why you might need to support multiple releases. Maintaining multiple codelines doesn't always mean you're not being
agile - particularly if each one of those is generating (or preventing the loss of) additional revenue .

While it may seem that having only a single stream of development is very restrictive, in practice it can work surprisingly well.  That generally means having to deal with a change or a fix where you first have to determine which releases need it,