The 7 Habits of Highly Effective Release Managers

Aha, the highly-effective series continues. Release management is often a misunderstood process, or capability, with the dividing line between it and change management often blurred. Let’s try to clear the blurriness in this blog.

Release management is the process that deals with major deployments, aka “the complicated stuff,” and its scope extends to hardware, software, networks, code, the cloud – anything that’s big enough and complex enough to need a significant level of coordination and support to deploy it effectively. How good your release management capabilities are – both initially and longer term – depends not only on your release management process but also the effectiveness of the people involved.

I like to think of release managers as being similar to air traffic controllers – their role is to co-ordinate and to be quick, efficient, and very, very safe. In the case of release management, instead of airplanes its IT services that are being managed – packaging together bundles of change into a single release to reduce periods of downtime and the inconvenience to the rest of the business.

It’s a high-impact process that deserves rock solid delivery, so here are my seven top tips for release managers being more effective in their roles – covering everything from acceptance criteria to playing nicely with colleagues in change management.

Tip 1: Understand the Difference Between Change and Release

It sounds obvious I know, but there’s still a lot of confusion about where change stops and release begins. So, let’s take a moment to figure it out, once and for all. 

Both change and release management sit in the service transition stage of the ITIL lifecycle, so both are part of the value stream that delivers effective business transformation.

ITIL describes change and release as follows:

• Change – the addition, modification, or removal of anything that could have an impact on IT services.
• Release – the collection of hardware, software, documentation, processes, or other components required to implement one or more approved changes to IT services. The contents of each release are managed, tested, and deployed as a single entity.

In other words, change is about installing, modifying, or retiring things safely without upsetting the business. It’s the day-to-day stuff, the kind of activity that IT departments do as a matter of course. Release management is a more holistic process that bundles together multiple changes into a single deployment in order to stop change management and the change advisory board (CAB) from getting overloaded.

Tip 2: Have a Release Policy

Like change management, release management simply doesn’t work without a policy. This isn’t an excuse to go all out putting lots of red tape around everything, but it is your opportunity to set out clearly what’s needed for the process to work as needed.

When creating a release policy, consider the following:

• Release identification – the numbering and naming convention to ensure that the right package is deployed to the right area.
• Frequency – scheduling needs to be addressed as part of the policy. How many releases do you need to have? Look at your organization’s appetite for change to drive this. Some organizations use a waterfall approach of defined release slots every month or quarter. At the other end of the scale you have the Agile model, which means a very frequent level of deployment. Make sure timescales are set in your policy so you can set expectations on how often new releases will be deployed to your environments.
• Requirements – the things needed to be considered for the release; for example, that only safe, authorized, appropriately licensed software from the definitive media library (DML) can be used in software deployments.
• Governance – that appropriate levels of governance must be in place to support the release management process. The policy should set out which releases can simply be authorized with change management at CAB and which releases need a higher level of approval, for example from a project or a release board.

Tip 3: Become a Master at Planning

If you have a rough idea of when a release needs to go in, then shout…and shout early. Work with change management, project, and deployment teams to raise an associated change record in your IT service management (ITSM) tool so that the release is visible to everyone and there are no conflicts or scheduling clashes.

Effective planning means that downtime and the associated inconvenience to the business is minimized as multiple items are packaged into one release. This approach also saves money as avoiding multiple downtime windows means less overtime, external support call outs, and potentially paying out for service credits. Just don’t forget to agree on your release window with your other stakeholders!

Tip 4: Standardize Everything You Possibly Can

When looking at how releases will be built and tested, automate everything you possibly can.

Automation might seem expensive but the economies of scale can be huge. Having automation also reduces the likelihood of human error and enables scripts to be templated and reused, reducing duplication. Not every organization can use automation, so if you can’t automate, then just standardize everything you use. Make sure to have agreed templates for scripts, testing, and documentation for ease-of-use and consistency.

Tip 5: Use Quality Gates as Enablers, Not Blockers

The point of release management is to enable the business to work with new or updated services. But, if handled the wrong way, instead of being enablers, release managers become blockers – doing the very thing they wanted to avoid, causing the business pain.

One way to make release acceptance less cumbersome is to introduce the use of quality gates. Put simply, quality gates are a way of enabling your release to move through the process quickly and safely making sure that all the quality criteria have been met. These are a set of predefined quality criteria that a software development project must meet in order to proceed from one stage of its lifecycle to the next.

Quality gates speed up the acceptance process by automating checks, standardizing tasks, and reducing cycle time because the release manager is getting it right first time.

Tip 6: Don’t Just Deploy Software, Transform Services

Effective release management isn’t just about rolling out hardware and software, it’s about deploying services to enable the business. If you’re uber-agile like Amazon, which releases software every second, it requires a very different approach than the one used by more conservative organizations such as healthcare, pharmaceutical, or financial institutions.

So, plan your roll-out strategy accordingly. Big bang, phased, pilots, delta releases, parallel, and push and pull deployments are all valid options depending on the organization. The reality is that release managers need to be knowing their business to pick the right approach for their organization.

Tip 7: Use Reviews to Make Improvements

Improve, improve, improve. That’s my mantra.

What’s the biggest opportunity to improve the quality of releases? Why, it’s to carry out post-implementation reviews of course! 

A post implementation review should be held after each major release to track any outstanding actions and to document any lessons learned. Inputs to a post implementation review could include:

• Incidents associated with the release
• Problems and known errors associated with the release
• Service desk feedback
• Customer feedback and satisfaction ratings

Outputs from the post-implementation review could include:

• Lessons learned, captured in a lessons learned log
• Known errors and workarounds
• Confirmation that the configuration management database (CMDB)/configuration management system (CMS) has been updated appropriately
• Service improvement suggestions
• Breaches to service level agreement (SLAs)/operational level agreements (OLAs)/ underpinning contracts (UCs)
• Updated work instructions

Capture any ideas for improvement in your continual service improvement (CSI) register or lessons learned log so everything is documented and prioritized, and the really great ideas are acted on. What’s not to love?

What are your tips for being a highly effective release manager? Please let me know in the comments!