Agile release management is an important starting point before advancing continuous intergation and delivery to continuous deployment.

In my last post, I asked whether continuous deployment is right for all businesses.

I suggested several business criteria and technology capabilities to determine whether to extend continuous integration and delivery to continuous deployment. I recommended in an earlier post that release management strategies are important to agile practicees. 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 Agile Release Management Practices

Many organizations start with ad hoc release practices. They let individual product owners, with or without the agreement of their development teams, to male releas decisions. They 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.

• Teams usually don’t act in isolation and their schedule may create conflicts when they require participation from shared service teams.
• Ad hoc releases complicate forecasting roadmaps. The amount of overhead tied to different release schedules may not be consistent across releases.
• Teams can create quality issues without guidance on what types of changes are appropriate for shorter versus longer release cycles.
• 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.

Escaping the frequent patch release spirals

Over the years, I’ve guided 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 Agile 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.

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 shorter durations with less time for users to review changes, so a minor release’s scope targets improvements that have less impact and technical risk.
• Third, major releases don’t have undefined durations. Product managers and delivery leaders should normalize release durations 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. Teams can then project the duration for this type of upgrade.

Estabish agile release cadences

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 on agile release management

• Defining the Agile Planning Sprint – Feature Estimation
• The What, Why, and How of DevOps
• DevQOps – Giving QA a Seat at the DevOps and Digital Transformation Table
• 10 Best Practices in Configuring your Agile Project Management Tools
• Ten Ways To Improve IT Culture with Agile, DevOps, Data, and Collaboration