Top 5 Red Flags Enterprise Release Management Is Failing

MAY, 2019 by Mark Henke
Taking enterprise release management seriously is a great step toward helping our organization flourish. Embracing release management will allow us to make the invisible visible. We’ll be able to effectively manage how work flows through our teams and into the hands of our users. However, it’s no silver bullet. It provides a lens through which we can view our releases, but trouble can still brew within them. In this article, we’ll look at five red flags that can plague our release management and touch upon how we might turn these flags green.  

1. Large Lead Time to Customer Usage or Testing

When we’re managing enterprise releases, our goal is to get something into our customers’ “hands” as fast as possible. This provides two benefits: feedback and revenue. Revenue fuels us to keep producing more releases and is an obvious reward. Fast feedback is not as obvious. Our first red flag is when we see large lead times for releases, indicating overly large delays. There are two types of lead times I want to cover here: total lead time and lead time between production deployment and customer testing. Large lead times reduce our profit—because of the cost we spend before we can earn revenue—and delay feedback.

Fast Feedback

We want fast feedback loops because we want to produce the right things for the least amount of effort. By getting a release to our customers, we learn. We learn how valuable it is, what our customers prefer, and what might be valuable to work on next. Nothing can replace this. Nothing. No fleet of business analysts will ever match the feedback of the customer experience.

Large Releases

The first way to see the red flag of large lead times is to look at the total time it takes for a release to go from inception to customer usage or testing. This indicates that we’ve bloated our release scope. A release can be doing too many things at once, even if it’s well managed. We need to slice it down into smaller chunks. Figure out and prioritize what the most important pieces of the old release are and make each piece their own new release. If your releases are measured in months, work with leadership to get it down to weeks.

Production to Customer Usage

The second lead time that red flags our releases is the time between when a feature gets deployed to production and when it gets used by customers. This usage could be revenue generating or acceptability testing. I’ve often seen where a team deploys a feature once a week or every two weeks. Then those features sit there for two months waiting for their customer, usually another enterprise team, to actually validate them. Inevitably, a lot of rework occurs and a lot of time is wasted. In the worst case, the team finds out some of the features were never needed for the release. This also demoralizes the development team producing the features. Why should they worry about their deployment rate when the code just sits there? It causes a vicious cycle, as the teams throughout the release become comfortable with slow deployment frequencies, lengthening the release even further.

Swarm and Norm

Instead, we want to norm with our customers. We want to collaborate on usability testing cadences for each feature before the release is done. The teams should be prioritizing around the same features within the release. It’s also an option for the teams to swarm together. A faster team can embed themselves in the slower team’s space for a while, helping them catch up.

2. High Ratio of Blocked User Stories per Iteration

The next enterprise release management red flag is the number of blocked user stories per iteration. Within each team is usually a number of handoffs and dependencies needed to push their features to done. When these dependencies start frequently getting in the way of the team finishing work, the whole release grinds to a halt. Dependencies blockages often come in two flavors: prioritization and coordination.

Prioritization Blockages

Like we mentioned for customer usage lead times, if two teams are needed to complete a feature for a release, they need to have the same priority. Here’s a simple example: Team A is working on Feature 1, but they need Team B to finish writing an API contract. Team B, however, is working toward Feature 2. Team A will spend a few weeks with user stories for Feature 1 blocked because of this. We can fix this by ensuring we have strict prioritization of features among teams involved in a release.

Coordination Blockages

Even if teams prioritize working together, they don’t work at the same pace. It may inevitably occur that one team is waiting on another team to finish their work. If one team is commonly slower, you can plan features so that the slowest team will start on the work first. However, these coordination problems usually have different causes. It’s fair to question why the dependency exists in the first place. For example, if I need to request database changes to a DBA team, perhaps we could change the schema ourselves and the DBA team can audit them later for compliance. The second thing to remember is that we’re all part of the same organization. Why not mob together? The two teams can go into a room together and bang out some code until the blockage is resolved. We want to keep our eye out for blockages to keep them low throughout a release, or we will have slow, demoralized teams.

3. Releases Are Planned Without Input From the Teams Doing the Work

One red flag I loathe is when a release is planned without input from the team. Does it make any sense to march a team toward a deadline that wasn’t based on when they think they can get the features done? If we aren’t using expert input from the team to plan out releases, then what are we basing them on? This sort of “arbitrary deadline” planning happens all the time. And while external deadlines happen, the release manager should understand the scope of the work is likely to be cut. Input on this should also come from the team. Anytime we force teams to an externally driven deadline with the fixed scope we go on a death march. And death marches ensure teams will just slog through stories, instead of energetically carrying them to completion.

Use the Past for the Future

When we’re planning a release, let’s gather input from the team. This can mean asking them to t-shirt size a set of features. Even better, it can mean we all story map a release together. We can even automate the process.  A release manager can take the historical cycle time and throughput of all the teams and use a Monte Carlo simulation to forecast when the release will likely complete.

4. No Market Analysis or Data Gathering Has Been Done for Multiple Releases

It’s astounding the number of times I’ve seen releases come through the pipe because one executive had a chat with another about how awesome an idea would be. This red flag covers releases or features that aren’t based on any market research or data gathering. We need to vet all ideas outside of our own biases. Enterprise releases are expensive, and we need to use data to gain confidence that, when we are done, they will make our company money. A release is only valuable if our customers use it. The effort we put into a release alone has no connection to its value.

5. The Team Members Participating in a Release Don’t Understand What’s Going On

Enterprise release management tools give a lot of clarity to those who use them. But it can be a red flag when those who can’t see the tool or don’t know about it lack that same clarity. Human beings have a tendency to assume that other people know the same things they know. It’s very common to see leaders saying “why doesn’t my team understand why this is important?” when they’ve never actually explained a goal to them. Even if they’ve talked about it, there’s no guarantee they use terms and explanations that their team will understand. This red flag occurs when the release managers know the release exists and its overall road map, but the teams participating have little to no clue. This lack of clarity is a risk because the teams can’t perform well if they don’t know what they’re performing for. The purpose is a key driver of motivation and performance. If a team doesn’t know their purpose, they’ll be slow and make decisions that go against the greater goals. The teams need not know everything about a release, but they should share an understanding about it that goes two degrees beyond the work they need to do.

Release Management Is a Lens

Release management tools are very helpful. But they can’t fix everything for us. They do provide a lens through which we can see where our red flags may be. We still have to diligently root out any such flags and make our releases stronger. We can’t let issues like long lead times or a high number of blockers recur, or we’ll cost our organization lots of money and demoralize our teams. This requires communication across multiple teams and a mindset of continual learning. When we’re disciplined about our releases, we’ll be green across the board.  
Mark Henke This post was written by Enov8 blogger Mark Henke. Mark has spent over 10 years architecting systems that talk to other systems, doing DevOps before it was cool, and matching software to its business function. Every developer is a leader of something on their team, and he wants to help them see that.

Relevant Articles

Sand Castles and DevOps at Scale

03JUNE, 2022 by Niall Crawford & Carlos "Kami" Maldonado. Modified by Eric Goebelbecker.DevOps at scale is what we call the process of implementing DevOps culture at big, structured companies. Although the DevOps term was back in 2009, most organizations still...

Test Environment Management Explained

Test Environment Management Explained3JUNE, 2022 by Erik Dietrich, Ukpai Ugochi, and Jane Temov. Modified by Eric GoebelbeckerMost companies spend between 45%-55% of their IT budget on non-production activities like  Training, Development & Testing and lose 20-40%...

Serverless Computing for Dummies

3JUNE, 2022 by Eric GoebelbeckerWhat Is Serverless Computing? Serverless computing is a cloud architecture where you don’t have to worry about buying, building, provisioning, or maintaining servers. In return for structuring your code around their APIs, your cloud...

Test Environments – The Tracks for Agile Release Trains

25MAY, 2022 by Niall Crawford & Justin Reynolds. Modified by Eric Goebelbecker.So, you’ve decided to implement a Scaled Agile Framework (SAFe) and promote a continuous delivery pipeline by implementing “Agile Release Trains” (ART)*.  Definition: An Agile Release...

What Is Data Masking and How Do We Do It?

24MAY, 2022 by Michiel Mulders. Modified by Eric Goebelbecker.With the cost of data breaches increasing every year, there’s a need for higher security standards. According to IBM’s 2021 security report, the average total cost of a data breach has risen to $4.24...

Test Environments: Why You Need One and How to Set It Up

24MAY, 2022 by Keshav MalikWith the rise of agile development methodologies, the need to quickly test new features is more critical than ever. This is especially true for websites and applications that rely on real-time data and interaction. The only way to ensure...