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 practice s, 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
- 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.
- Define release types that correspond to the impact to users and technical risks . Presented below are three typical release types.
Release Type Scope Typical Duration Major New features and capabilities. Workflow changes. No changes to underlying systems, app infrastructure, and libraries 3-6 sprints Minor Small changes and fixes. No new capabilities or system changes 2 sprints or less System Upgrade Changes to systems, app infrastructure and libraries with no or minimal functional changes 1+ 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.
- 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.
- 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.