What is release management? 3-step process for agile teams

Your release strategy is key to how fast you can learn — or damage your image.

After working on a secret feature for a few sprints, it was finally time to get it live. Everyone felt nervous and excited as we prepared to release our state-of-the-start marketplace integration.

What could go wrong?

We worked on it for over a month, ran automated tests, and followed our plan. Without hesitation, we hit the button to go live and waited for feedback, which didn’t take long.

Three minutes after the release, I got a call from the marketplace director. His voice was aggressive and I felt anxious. He said:

“Whatever you’ve done, revert it now. All products evaporated from our marketplace. Every minute you take to get them back will cost us money and reputation.”

How did we get there?

Unfortunately, as with many teams, we had a big-bang deployment. Despite calling ourselves scrum teams, we weren’t equipped to learn fast enough.

In this guide, I’ll demonstrate how you can avoid this painful experience by implementing a simple, three-step release management process.

What is release management?

Defining how often to make your product available is an important consideration for any team. This is known as release management.

The more modern the company is, the more frequent releases occur. For example, Amazon makes several product releases a day. This is possible due to continuous deployment, which also makes it easier to revert changes when necessary.

Other companies release less frequently in bigger chunks. This approach makes it harder to release software because it requires more complex versioning, merging, and quality assurance.

The more frequently you release, the easier it is to react to problems.

What does a traditional release management process look like?

A traditional release management process can be visualized as a cycle consisting of the following stages:

• Planning
• Scheduling
• Controlling
• Testing
• Deployment
• Managing

Though each is important, as we’ll touch upon below, we won’t get too in the weeds about the individual stages of the release management process. Instead, we’ll highlight some traps and antipatterns agile teams commonly fall into when releasing changes and outline a new three-step process to help ensure your future deployments go more smoothly.

---

---

Common problems and antipatterns when releasing changes

In decades past, releasing software to end-users used to be a big day.

I’d compare it to launching a rocket into space. Many specialists get together, evaluate dozens, if not hundreds, of items, and decide whether the launch takes place. The stakes are high. No mistakes are allowed.

Releasing software used to have that feel of urgency. You’d find the following:

• Rollback plan — Getting something live was hard; reverting it was a nightmare. Teams had to create a rollback plan to ensure they knew what to do when things went wrong
• Test plan — Most companies have a massive plan to evaluate whether a release is successful. A set of people are responsible for running exhaustive tests manually, creating bug reports, and delivering them to software engineers
• All or nothing — Either you make the feature available for everyone or no one. That’s why everyone was so cautious with deployment. It would impact the whole user — meaning that if you do something, everyone will notice
• Deployment engineer — Releasing meant a lot of responsibilities. Probably only one or two people on the whole team would have access to push the “release” button
• Multiple levels — Before releasing software to production, teams would go through different stages, potentially including a development environment, staging, and then pre-production. All of this is to avoid a catastrophe in a live environment

Despite these cautious measures, teams still face unforeseen problems and must work intensively to solve problems. The antipatterns and traps described above are supposed to be relics of the past, but I still see some of these traits today.

A 3-step process for successful release management

The problem with the above-mentioned points isn’t only speed but also the cost and massive time-suck of fixing issues.

Fortunately, there’s a way to release changes that is much more efficient and enables you to gain better insights to continuously improve. All you need to do is follow these three steps:

1. Limit the blast radius
2. Release quickly
3. Measure results

1. Limit the blast radius

One of the core parts of agility is our ability to accelerate learning. It’s fundamental to test our ideas as fast as possible.

However, that doesn’t mean exposing new features to your whole audience. This is a dangerous bet that often backfires.

It’s essential to increase our ability to learn from users. For that, limiting the audience is vital:

• Limited reach — Ability to reduce users to use new features; for example, 1 percent of the whole audience. It’s possible to scale gradually
• Tailored audience — Most of the time, you want a specific audience to test your new features. This enables you to learn from people you aim to create value for; for example, users who bought something over the last four weeks.

Why not just release changes to everyone at once? It’s simple: in the beginning, you want to build to learn, then scale if it makes sense.

As a rule of thumb, you should assume that nine out of 10 ideas won’t work as expected. It’d be unwise to show your bad ideas to your whole audience.

2. Release quickly

How easy is it for you to get your software in the hands of users? Do you get nervous before releasing or enthusiastic about the opportunity to learn from your audience?

Traditionally, companies plan releases and prepare for the big day. This should be a thing of the past.

Let me put it this way: the faster you release, the quicker you learn. That’s important because you probably won’t get things right from the beginning.

Product-led companies do several releases per day; outdated companies do, at best, one release per month.

The longer you take to get your work in the hands of users, the bigger the bet becomes. Unless you want to rely on luck, that’s not the way to go. We already have better ways of releasing.

Releasing changes should be trivial; it should happen in a matter of minutes.

Rolling back should be the same. If you work with continuous deployment, that’s old news to you, but many companies still don’t.

Ask yourself, would you trust a junior software engineer to release changes in production? If your answer is no, you lack a fail-safe release process.

3. Measure results

Alright, let’s say you can tailor your audience and release changes in minutes. What else do you need? Isn’t that good enough? Not so fast.

The beauty of a value-driven mindset is understanding whether you’re creating value. You’ve got to remain curious.

---

---

Users will surprise you. It doesn’t matter how much effort you put into discovery, assumption testing, etc. Once people start using your new shiny features, they will come up with something unexpected. It’s essential to learn from that.

It’s a common antipattern to get features live and then jump to the next one or search for confirmation that you’re doing it right. Neither one nor the other will help you create value faster.

Everything you create is a means to an end. I imagine you know what you want to achieve with something before you start working on it. I’m saying that once you get something live, you need to figure out whether you’re reaching your goal.

Segmented tests  —  better known as A/B tests  —  are commonly used to measure results. They’re helpful when you’re improving something and comparing the results. While I’d highly recommend you A/B test, you don’t have to limit yourself to that approach.

The key is to measure the result of whatever you made available for your audience. Aim to act based on evidence. Once you learn something, you can inspect and adapt. The name of the game is creating value, not shipping features.

Conclusion: Learn from my mistakes

I started this article with a story in which my team got it all wrong. We had a big-bang deployment to our whole audience and everything collapsed in a matter of minutes. It took us days to fix the mess we caused and months to recover our credibility.

Don’t do what we did; invest time getting your teams ready to handle releases as smoothly as possible. The benefit is incalculable.

Featured image source: IconScout