Defining Your Agile Release Management Strategy

Release Management
In my last post, I asked whether continuous deployment is right for all businesses and suggested a number of business criteria and technology capabilities to help determine whether organizations should go beyond continuous integration and continuous delivery to a full continuous deployment operation. I recommended in an earlier post that release management strategies are important to agile practices, however, maturing to continuous deployment is just one, rather advanced approach, Organizations can still achieve high quality software releases and develop product delivery roadmaps with more traditional release management practices.

The Problems with Ad Hoc Release Management Practices

Many organizations start with ad hoc release practices and leave it to individual product owners with or without the agreement of their development teams to decide when applications are ready to be released, when to schedule release dates, and how frequent to schedule them. Leaving it to individuals or teams to make these decisions leads to several potential issues. First, these teams usually don't act in isolation and their schedule may create conflicts when they require participation from shared service teams. Second, the ad hoc nature makes it more difficult to forecast roadmaps since the amount of overhead tied to different release schedules may not be consistent from release to release. Third, these teams can create quality issues if there isn't some guidance set on what types of application changes are appropriate for shorter versus longer release cycles. Lastly, these teams tend to want to make "quick fixes", "patches", "support changes", or "emergency changes" frequently and without realizing that this makes it difficult to focus on more strategic application improvements.

Over the years, I've been brought into several organizations stuck in this cycle of frequent patch releases. The team makes one release, the product owner reports user complaints or production issues and demands fixes, the team complies with a patch release that only partially fixes the issues, the product owner reports additional customer feedback as defects, the team chases it with another patch release and this cycle repeats. If this continues, users get frustrated with the quality of the application, teams get the reputation of having poor practices, and product owners fail to deliver on their strategic roadmap.

Getting out of this cycle is critical and many teams can't do it easily on their own. They need someone to lead them through steps that (i) recognize the issues created by ad hoc release practices, (ii) define release principles that make sense for the business strategy and for users, (iii) take active steps to normalize their release management practices.

Defining Release Management

Here is a summary of the steps I specify with organization that want to go from ad hoc release schedules to a normalized release management practice

  1. Define a frequency of change that makes sense for the business strategy and for users. A B2C company that targets small experimental changes may want more frequent releases than a B2B company that's producing analytics for their customers. Keep in mind that any release that contains new capabilities, functional changes, workflow changes, or substantial UI changes often requires some form of testing and user training, so the release cadence should align with how easy it is to engage the user community on new capabilities.

  2. Define release types that correspond to the impact to users and technical risks. Presented below are three typical release types.

    Release TypeScopeTypical Duration
    MajorNew features and capabilities. Workflow changes. No changes to underlying systems, app infrastructure, and libraries3-6 sprints
    MinorSmall changes and fixes. No new capabilities or system changes2 sprints or less
    System UpgradeChanges to systems, app infrastructure and libraries with no or minimal functional changes1+ sprints to test, then validate impact

    You'll notice a couple of things. First, I instill testing disciplines by having releases focus on application changes (major and minor releases) versus system changes (system upgrades) which provides scope to the testing required. Second, minor releases are characterized by shorter durations that have less time to engage users on changes, so the scope of minor releases is tied to improvements that have less impact and technical risk. Third, major releases don't have undefined durations and the duration should be normalized to the business strategy and technical capabilities of the organization. Lastly, it's hard to determine the duration of a system upgrade, so I advise teams to plan at least one sprint to test the upgrade and add to the backlog the issues that need remediation. Once these are identified, the team can then project the duration for this type of upgrade.

  3. Your release starts when planning the release, not when you're ready to deploy. This is a change  the team needs to recognize. Deployment planning which goes into defining the technical steps to push an application into production is not the same thing as release planning. Release planning should start before any development starts. It should start by defining the business goals, selecting the release type, and defining at least part of the backlog for what needs to be developed. It should include defining what business activities are required pre and post the release. Once this scope is understood, then a target date can be selected for the release.

  4. Look to establish a schedule of releases. Once a team has been through at least one successful release of every type, it can then explore developing a release strategy. This strategy should factor in how many major releases the business team requires, how many system upgrades are needed to keep technologies up to date, and how best to schedule minor releases. 
Once these practices and governance are in place, then optimization leads to shorter release cycles and the capability of performing more frequent releases. I'll leave that to another post.

Further reading 

1 comment:

  1. God bless you Isaac! You've captured in simple terms the essence of Release Mgmt. Specifically thank you for highlighting the need to separate this from Deployment Mgmt. AND for the table showing that it's likely multiple sprints feed into a Release. Too many still think Done in a Sprint = In Production. Personally, Scrum Masters really need to get a better handle on this as they can help the team understand.


Comments on this blog are moderated and we do not accept comments that have links to other websites.


About Isaac Sacolick

Isaac Sacolick is President of StarCIO, a technology leadership company that guides organizations on building digital transformation core competencies. He is the author of Digital Trailblazer and the Amazon bestseller Driving Digital and speaks about agile planning, devops, data science, product management, and other digital transformation best practices. Sacolick is a recognized top social CIO, a digital transformation influencer, and has over 900 articles published at InfoWorld,, his blog Social, Agile, and Transformation, and other sites. You can find him sharing new insights @NYIke on Twitter, his Driving Digital Standup YouTube channel, or during the Coffee with Digital Trailblazers.