The Problems with Ad Hoc Release Management Practices
Defining Release Management
- 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.
- 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