DevOps and continuous delivery changed the game for release management, but there’s still value in the release manager’s position. We explore the changing role of release managers when much of their job has been automated away.
What is release management?
Release management is the practice of planning, scheduling, and managing the software release process, from development and testing through to production.
When Waterfall methodology was the dominant approach, releases were often only an annual or biannual affair. With the adoption of Agile methodologies, businesses have moved to more frequent releases of smaller, iterative improvements to their products and features.
Frequent releases are great news for end users, who don’t have to wait as long for new features, bug fixes, or better functionality. But with the uptick in releases, the number of stages in the software delivery lifecycle, and the number of stakeholders involved, the software release process is complex and the risk of errors high. So, the role of the release manager emerged.
What is a release manager?
To understand the role of release managers, it helps to start with what the release process looks like without one:
- Inconsistent build and deployment processes are across teams.
- Communication failures and friction among teams.
- Inconsistent versioning practices.
- Inconsistent configuration management.
- Delayed releases.
The release manager is responsible for planning the release calendar and coordinating across functions at each stage of the release cycle, ensuring that all approvals are in place and new features or functionality are delivered successfully, without causing issues in production.
“A release manager is the person who's accountable and responsible for making sure that features or any work is available to customers,” explains Carmen Quan, engineering manager at LaunchDarkly. In some organizations this is a permanent position; at others the role is rotated among team members.
What background and skillset should release managers have?
Release Managers are usually qualified with a degree in Computer Science or a related field, however some may instead be hired or promoted into the role based on relevant years of experience in software engineering and the software development lifecycle. It’s also not uncommon for people to transition into release management from a variety of different teams, for example a prior role on a development team or operations team.
Below are some of the core abilities, experience, and technical skills required by release management roles:
- Problem solving
- Project management
- Communication skills
- Stakeholder management
- Understanding of product management
- Experience with change management and Scrum methodology
What is the role of a release manager in DevOps?
As DevOps has become the prevailing approach to the software development lifecycle, some aspects of the release management process have changed, along with a shift in release managers’ responsibilities.
Is release management still relevant?
Release management is much less of a topic of discussion than it used to be. Google Trends data for the past decade show that global interest in release management peaked around 2015 and has been declining steadily since.
ReleaseManagement.org, a dedicated resource on the subject, launched in January 2016 and abandoned posting just four months later. It seems like release management has all but disappeared from industry discussions. Does this mean that a release manager’s role in DevOps is obsolete?
The evolution of the release management lifecycle does mean a shift in focus for release managers, and evolving job descriptions. The release manager is still responsible for delivering a high-quality, successful release, but the methods by which they get there have evolved. It’s likely that discussions around managing the release and software delivery process are happening without explicitly referring to “release management.”
Continuous delivery and release management
DevOps practices and their emphasis on automation have led to many companies investing in continuous integration and moving towards a continuous delivery model.
Continuous integration: The practice of regularly integrating code changes from multiple developers into a central repository. An automated build and tests are then run to surface any problems with the new code.
Continuous delivery: Goes a step further than continuous integration by sending every successful change to a staging environment, automating the full software delivery process. Deployment to a production environment can then be triggered manually by a developer. With continuous delivery, deployment of software is decoupled from releasing that software to end-users. The goal is for all code to always be in a deployable state, making more frequent software releases easier to attain.
Even going from releasing new software once a month to twice a month is a huge jump for organizations, so the release processes that worked before aren’t going to cut it. With automation tools enabling more frequent releases, organizations practicing continuous delivery may be releasing multiple times a week or more. In this environment, what is a release manager’s role?
The idea that release managers have automated themselves out of one job and into another is explored in the DevOps.com webinar, “The Release Manager is Dead. Long Live the Release Manager!” This is good news. The role of release manager has usually been a stressful one; coordinating many moving parts and ultimately being on the hook for a successful release. DevOps and continuous delivery practices enable releases that comparatively feel more like “non events.”
A lot of the release activities that were necessary before are now automated away. There isn’t a release plan or release schedule to manage. Ideally, much of the project management and stakeholder management has either been built into or made obsolete by the processes that a feature undergoes on its way to release.
The next phase of release management: progressive delivery
“I'm always a fan of eliminating as much human error as possible and I think part of the role of a release manager is defining roles, guardrails, or mechanics that prevent human error,” says Carmen. One way to reduce the possibility of human error and the risks associated with continuous delivery is to evolve your release management practice into one of progressive delivery. There are two characteristics of progressive delivery to understand, release progression and progressive delegation:
Release progression: The practice of releasing software or features to end-users at a cadence that works for the business. This could mean shipping continually or gradually to subsets of users. This builds on continuous delivery’s decoupling of software deployment from software release.
Progressive delegation: Assigning control of a feature to the team most responsible for the outcome. Over the course of a release cycle, a feature may be delegated to engineering, then product management, then product marketing, and so on.
Together, these practices reduce risk and empower the most relevant team members with more control throughout the release cycle. There’s one more concept to introduce that’s key to enabling progressive delivery: feature flags.
How feature flags take the stress out of releases
Feature flags (or feature toggles) are used to enable or disable functionality in software remotely, without deploying new code. They allow you to roll out a new feature without making it available to all users, so you can test it safely without changing the experience for your customers until you’re ready.
“What feature flags allow us to do is decouple the idea of releasing a feature with deploying code. The reason [the release manager’s role is] high pressure is every time you deploy code, it feels like you're making a change. The theory behind feature flagging is that these are now two different things altogether. You can continually deploy code every single time a change is made, but until you toggle a flag on or off, nothing changes for the customer.”— Carmen Quan, Engineering Manager at LaunchDarkly
Because changing the availability of the feature or functionality in question is controlled by a feature flag, it’s as simple as flipping a switch. When we think about release progression, that gradual rollout of features is possible with a feature flag targeting a subset of users. Feature flags enable progressive delegation easily, since handing over control of a feature simply involves transferring ownership of the feature flag to the relevant team.
What is the role of a release manager in progressive delivery?
You might be wondering what there is left for a release manager to do if the “release process” is reduced to flipping a switch. Automating releases frees up release managers to add value instead by monitoring metrics, reporting on them, and guiding future iterations based on customer feedback. In some cases release managers can also help by iterating on the release process itself, based on insights drawn from metrics.
Release manager … turned value stream manager?
“Historically, release managers have looked at what I would call classic project management-type metrics: Gantt chart oriented, weeks and months and milestones and schedules and deadlines. Value stream management is bringing in a different set of metrics.”—Brian Muskoff, Director of Development, HCL DevOps, "The Release Manager is Dead. Long Live the Release Manager!"
Brian goes on to share two types of new metrics release managers can pay attention to: efficiency measures such as cycle time, lead time, and wait states; and operational metrics, such as mean time to resolution, change failure rates, and ultimately predictive analytics (forecasting the probability of defects in new code). Release managers can also pay attention to how customers are managing with a new feature. These data points are easily available, but they need someone overseeing the bigger picture to bring them together and communicate their business impact.
Release managers have a vital role to play in not only tracking these metrics, but also identifying dependencies, potential bottlenecks, and opportunities to optimize processes and timelines.
.webp)
