In a way, release management starts when an organization no longer views releases as events that are impossible to manage. Also, when releases become less and less of an opportunity to showcase every disconnect between departments.
Given the fact that nothing really makes or breaks a project’s success like release management, and avoiding release slippage, we might as well look into it.
Why releases slip
When workload estimation is off
One of the reasons we fail to plan correctly is our inability to estimate the workload. And unfortunately for us, there is no golden ratio we can lean on to estimate how long it takes to fully complete development and testing. It’s tricky business, and even though we can’t perfect our estimates, we can still manage to estimate way better thanks to the assistance of proper project management tools.
Inflexible release timelines
Instead of sticking to hard dates that seem unattainable, we should be able to continuously change timelines; the fact that things change all the time is a key point here. This article is written at a time where the world has turned upside down because of a microscopic entity - a coronavirus - so what more proof do we need that things change all the time?
Project risk management 101
Project plans should include, not only the vision and direction, but also the various risks that might come along uninvited based on the direction we’ve already agreed upon. Basically, risks have to be managed and a release plan should be able to change as your release progresses.
How to avoid release slippage?
Now, there’s more to this than just estimating well.
Improve release visibility
Visibility is one of the key requisites when it comes to speedy, quality deliveries. Without end-to-end visibility of the release process, your releases are bound to slip. Which is why organizations should try their best to improve real-time visibility, by tracking their delivery time, understanding the scope and bigger picture of their releases, and fixing their overall team structures. I won’t get into details given we’ve already looked into what you can do to improve visibility over your releases.
Plan your release
The release planning stage is where your entire release is structured, from start to finish; a good release plan will help your team stay on track and avoid slippages.
Release management checklist
There are many ways you can map out your plan and clarify the process for everyone. One way to do that is by using a release management checklist. The checklist outlines the process functions and responsibilities, in some sort of a chronological order, so that your team members can quickly identify the step they’re currently on, and what their role or responsibility is.
Release workflow
During the planning stage, it’s important you create a release workflow that everyone in the team can refer to throughout the release; this workflow should explain how the whole release is staged and every stakeholder’s part in the bigger scheme of things. Your release plan should include timelines, delivery dates, requirements and overall scope of the project.
Once your plan is set, you can present it to all relevant stakeholders for review; their feedback will allow you to pre-solve the gaps and problems you may have to face later. Once your plan is finalized, then it’s action time.
Design and build your release
Once you’ve finalized your release plan, you can start designing and building your product.
Handle release issues
To make sure your team responds well to incoming issues/requests, you should have an overview of all issues across multiple releases. By linking those issues, you can add structure to your work and help everyone get better visibility of what’s happening with the release.
Allow the work to flow back and forth
Once you’ve dealt with the issues properly, it’s time to test your build in a real-world scenario. So, while the team is building the product, the latter needs to be sent automatically to the testing environment for user acceptance. This way, your team can identify issues and bugs and move to stage two development. Basically, this iterative release management process allows the work to flow back and forth until the release is approved.
QA is everything when it comes to release management
User acceptance testing (UAT) happens when your end user actually uses your product and gives feedback; I can’t stress how important this is. This phase is often offered as a free trial online or shared with employees within the company, and is pretty much the most important step in release management. This is where you collect data and prepare for the official launch. As bugs get identified, the team goes back to fixing issues for a better build; there’s no finalizing the release for deployment unless this stage is completed.
Deploy your release
Identify lingering issues
This is where your hard work should pay off; the time has come to release your product into a live production environment. During your deployment stage, lingering issues are identified and documented so that they can be addressed in the next iteration.
Use a collaborative platform
Release management is all about change; every single release is an opportunity to refine everything, from your workflow, to your checklist, to what works best as a release process for your team. The collaborative platform makes it easy for everyone to view the high-level plan and personal progress so that everyone is on the same page, always.
Adapt your release process
The Release Governance Framework is a fantastic, 3-step free tool that can help you build, review and adapt your release processes. It allows you to test what works for you and your team, then iterate and improve the way your team delivers. This is a quick read on how the Release Governance Framework can help improve your release process.
Calculate your release slippage
There are a few indicators that can always help you figure out what’s happening with your releases; they’re really useful to avoid slippage by keeping up with the numbers. Don’t get scared from the math, it’s actually quite simple.
Release Slippage Risk Indicator (RSRI)
RSRI shows whether at least a minimal viable release (MVR) can be deployed to production on your scheduled date. It’s calculated as follows:
RSRI = Past Sprint Productivity (P) / Required Sprint Productivity for release date (RP)
=1 as planned
<1 delayed
>1 ahead of plan
Sprint Burndown Performance Indicator (SBPI)
SBPI shows you the deviation in completed work compared to the work you planned for the current sprint. It goes like this:
SBPI = Ideal remaining work / actual remaining work
=1 as planned
<1 delayed
>1 ahead of plan
Scope Volatility
Scope volatility showcases the size change of your release scope, comparing the scope size measured at the start of your release and after the last completed sprint.
So much can be said about release slippage, but let's leave it at that for now. I hope this has given you decent insight into what can be done to avoid slippage before it's too late.