An Agile Approach to Release Management


For teams practicing Agile Software development, value working software over other artifacts, a feature from the release plan is not complete until you can demonstrate it to your customer, ideally in a shippable state. Agile teams strive to have a working system ("potentially shippable") ready at the end of each iteration. Release Management should be easy for an ideal agile team, as agile teams, in theory, are ready to release at regular intervals, and the release management aspect is the customer saying, "Ship it!."

Agile teams work under the same constraints as other software development teams.  They must 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 while maintaining discipline and good engineering practices.

We will discuss how release management works in an agile project and also explain how even non-agile teams can benefit from applying aspects of an agile approach so that value can be delivered to 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, detailed planning for these items
  • Integrate often
  • Verify often
  • Deliver and review against a plan

These practices affect how one thinks about release management, as it is a planning activity and any planning activity has uncertainty that increases the distance you are from the present. The goal of having features complete or not at the end of each iteration allows the user to determine 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 to focus on the highest value work, and also engineering (including SCM) discipline, which helps to identify and fix problems early, giving you more predictability. Agile practices make shipping a release a decision that 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.


The IT Process Institute's report on 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 predict top levels of performance more than the many of the industry recognized best practices in these areas.


User Comments

Evan Cutler's picture

This is a great article.  As a build manager, my organization has fully adopted the agile approach, and this article helped me identify how to cross the bridge between agile methdologies and release management/CI. I am researching what happens when a full product requires multiple sprints.  I realize that agile requires a usable and shippable product at the end of each sprint, but feature complete on the complete package isn't until sprint 4.  I am interested in knowing how release version management happens there.  Is Version 1 after sprint 1, or feature complete at sprint 4?  Thank you.

January 6, 2016 - 10:25am
Steve Berczuk's picture

It really depends on what makes sense for your team. If you are deploying internally for testing, you may want to identify each deployment as a version and then track which version you release. You could also flag your pre-release versions with a qualifier : 1.0-alpha, for example. The thing to note is that Scrum and other methods talk about a _potentially_ shippable product increment. So it's OK to no be feature complete, but nothing should be obviously broken. (or at least not obviously broken in an unknown way). If there is work in progress you can hide the incomplete work behind feature flags.


The main thing to aim for is to be able to show the current state of working code to stakeholders at the end of each sprint. Did that make sense?

January 6, 2016 - 12:23pm

About the author

About the author

About the author

CMCrossroads is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.