Top 5 Red Flags Enterprise Release Management Is Failing

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.

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