In the ever-evolving world of software, no company can quite afford to push out half-baked releases let alone delay delivery; yet it often so happens that releases slip.
Misalignment, visibility issues, delays, lack of structure, unnecessary work - sounds familiar?
While it’s true that great team collaboration requires time and effort, wise is thou who does not overlook processes. Simply put, a proper release management process can help materialize the necessary consistency, visibility and alignment, and encourage individuals to take better ownership of their work so that they may function well individually, and as part of a whole.
So, how can you improve your release process and ensure you have the optimal product release process?
RELEASE GOVERNANCE FRAMEWORK
The Release Governance Framework 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. By following three easy steps, you can actually manage to create better release processes for everyone involved.
Let’s start from the beginning, where you standardize your current process i.e. where you take a good look at what’s happening. Process assessment should help highlight your pain points and show you what works, and what doesn’t. Remember, this is a team effort so make sure everyone’s on board and somewhat looking forward to change.
You can use the Release Governance Workbook and run a retrospective with the team - everyone involved, even if minutely - so you can collect their feedback and get an idea as to how things actually happen. Say, you find out that your team is frustrated because the release date of a project keeps getting pushed, with stories constantly being added to the spread. On the other hand, you realize that your team is quite confident when it comes to delivering hotfixes for incidents; which is where they’re most efficient.
In such a situation, you may want to pick up some of the patterns from the hotfixes process - which seem to be working well - and try and apply those patterns to your normal delivery sprints.
Once you’ve gone through your current process, you can then start drafting new workloads using Workflow Builder. It would be great if you could brainstorm and agree with your team as to the different types and stages of your releases. Make sure to fill out all the types of releases and stages you have, to see what stages are relevant to what type of release, and how long these stages require.
Define your different types of releases based on what value they deliver to your business, their impact on customers, processes they go through, and so on; and try to keep the process as simple as possible. You can always iterate later. In this case, we’re looking at MVPs, improvements, hotfixes and bug fix sprints.
Second, include all the kinds of release stages or milestones your release could go through; all the in-between steps that ensure your release happens. In the simplest case, it could be research, design, development, regression test, bug fixes, smoke testing, and documentation update. You could also add many more stages; to each type, its own stages.
You can then agree on how long every stage takes, based on the type of release. Design and research would probably take much longer with an MVP than with small improvements on an existing product for example.
A piece of advice; try to keep the improvements release cycle as short as possible, so that you’re comfortable adding other requirements to your release. You just have to make sure you follow this as a team.
Create Release Plan Template
Once your team is on board, you can then create release templates that you’ll be using to track your releases and store your findings. You can create a new release plan template or update your current one to include information about the types of releases and stages; then fill all the relevant information.
Fill Release Plan Template
Whenever a new release is planned, make sure to fill a new template; that way your data is available and you can see whether improving your processes is really working. It’s also useful to have your team aligned on the goal of the release and expectations around the schedule.
Now that you have your data, it’s up to you to analyze, understand and iterate.
The time has come for you to analyze your releases so that you can see which to focus on improving next. By measuring your release health KPIs, you can ensure that you review what’s going well and what can be improved, and take action. For that, you can use Health Checker – which defines 3 main release health KPIs:
· % of failed releases
· % of slipped releases
· Number of releases per release type
It’s useful to go through these metrics on a project or team level. They will help you see what to focus on and who to talk to. Once you’ve tracked your release properly, say for a month or two depending on how long your release is, you can identify issues and optimize your process all over again with the team. It’s much easier to take action once you’re tracking release health.
Here for example, one of the teams has way too many hotfixes which means they’re constantly firefighting and probably underperforming as a consequence. Moreover, the other team is slipping on releases often and, based on the percentage, you can see that this team has spent most of its time fixing bugs.
In this case, we can look into whether the issue is related to code quality or work prioritization, and iterate from there.
Once you’re done, you can store your findings and make them accessible to everyone; it’s important you encourage team collaboration where people take ownership over many stages. If you manage to improve your release process, your organization will benefit on so many levels. Besides reduced cycle time, the benefits could include fewer defects, increased predictability, reduced costs and the list goes on.
Eager to start? Get your Release Governance Workbook here.