Top 5 Red Flags Enterprise Release Management Is Failing
1. Large Lead Time to Customer Usage or TestingWhen 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 FeedbackWe 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 ReleasesThe 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 UsageThe 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 NormInstead, 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 IterationThe 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 BlockagesLike 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 BlockagesEven 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 WorkOne 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 FutureWhen 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 ReleasesIt’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 OnEnterprise 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 LensRelease 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.
16September, 2021 by Carlos SchultsLet me start with a question: as a leader in tech, are you satisfied with the budget you have? If I had to guess, I'd say the answer is no. Because of that, calculating the return on investment of the many activities in software...
14AUGUST, 2021 by Ukpai UgochiIt is the goal of every software engineer and software development firm to continuously ship products to end users. This can only be achieved through software deployment. In this post, we'll explore deployment and deployment planning,...
09SEPTEMBER, 2021 by Eric GoebelbeckerLet’s talk about container essentials. Over the past few years, containers have transitioned from the hottest new trend to essential IT architecture. But are they are good fit for you? Are you wondering whether or not you’re using...
05AUGUST, 2021 by Alexander FridmanIn the beginning there was nothing. Then there was the monolith, though we used to simply call monoliths "software." Today we have two rival architectural types: monoliths and microservices. This post will explain what monoliths and...
15JULY, 2021 by Justin ReynoldsCompanies go to great lengths to protect their physical environments, using deterrents like locks, fences, and cameras to ward off intruders. Yet this same logic doesn’t always translate to digital security. Corporate networks — which...
06JULY, 2021 by Justin ReynoldsCompanies today face increasing challenges around reducing the time and cost of software development. Many are thus using DevOps methodologies, which combine software development and IT operations to achieve continuous delivery and...