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.
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.
A traditional release management process can be visualized as a cycle consisting of the following stages:
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.
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:
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.
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:
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:
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.
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.
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.
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
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
A fractional product manager (FPM) is a part-time, contract-based product manager who works with organizations on a flexible basis.
As a product manager, you express customer needs to your development teams so that you can work together to build the best possible solution.
Karen Letendre talks about how she helps her team advance in their careers via mentorship, upskilling programs, and more.
An IPT isn’t just another team; it’s a strategic approach that breaks down unnecessary communication blockades for open communication.
Learn more →
