Note: Originally published on LinkedIn
Many people liken bottlenecks in software delivery to bottlenecks in manufacturing, and that isn’t an unreasonable comparison. Nevertheless, there are significant differences, not the least of which is that manufacturing bottlenecks tend to be easily identifiable. This is largely due to the measured nature of manufacturing where work flows through specific cells, and it’s pretty evident when one gets jammed up.
Software bottlenecks are more complicated to diagnose and resolve because they aren’t always obvious. For example, one process might be two weeks behind, but if it’s at the end of the delivery cycle and few other activities are reliant upon it, that may not be an issue. An activity that has been held up for only a few days could cause much greater disruption to software delivery flow based on its importance and the other activities that rely upon its completion.
That difference is at the core of understanding how to identify true software bottlenecks effectively. Recently, our SVP of Products Andrew Fuqua and I had the opportunity to talk about them — how bottlenecks can show up, effectively be evaluated, and then either eliminated or dismissed as inconsequential.
Software Bottleneck Basics
Let’s assume a company with aggressive deadlines and complex requirements for software development is running on a scrum framework. During the software development lifecycle, the quality assurance team might be idle at the beginning of the sprint, but they may be overloaded at the end of the cycle. At that time, the developers might be idle. That makes cycle time an unreliable metric, because a bottleneck may move around or cycle times may move around, and there is no guaranteed pace or continuity.
In addition, unlike manufacturing processes, software development cycles aren’t highly repetitive. They are much more unpredictable because various departments and stakeholders can elevate some cycles to higher priority, while others may get pushed into backlog and sit there.
Even if a cycle holds greater business value, if someone is able to intervene and prioritize other cycles, process efficiency has been diminished. The “value stream” has also been disrupted, since changes that have higher value from a business perspective are not moving at the optimal pace.
Conversely, it’s equally possible for software to move through a particular stage too slowly or for a step in a process to take too long or be deferred altogether. However, hold ups like that are not necessarily what impacts flow.
Consider the example in Figure 1 below. The average person, looking at it, would immediately assume that deferred testing, which is adding an average of 3 weeks to the delivery cycle, must be one of the most significant impediments to efficient software flow.
In reality, if we were to dig a bit deeper, we’d discover that the delay in testing is responsible for only a few trouble tickets out of hundreds. As the graph in Figure 2 indicates, quality assurance has only a 3.7 day bottleneck, but there are 166 trouble tickets for that state.
In essence, the first chart is very misleading, and anyone relying strictly upon those metrics would likely address the wrong bottleneck first. That could lead to significant delays, missed delivery dates and potentially serious client and/or stakeholder disappointment.
If teams chart the average times in states, things get a little bit better, but they can still be misleading. In our experience, a good option is to set up a box plot (Figure 3), which illustrates the range of these states.
It also enables us to see stages with very broad ranges and a lot of outliers. From there, we can dig into these outliers and see if the same set of them is occurring in every state, or if they are different. Perhaps most importantly, we can look at the state (or states) that have the most variation and try to eliminate some of the common causes.
These are just a few examples of how we can effectively pinpoint true bottlenecks — and suspected ones — and address them.
Final Thoughts
In essence, there is a world of hidden data that is not readily apparent in many charts and graphs. Software teams often become bogged down trying to apply the metrics and graphics with which they are most comfortable to extract insight for resolving their bottleneck scenarios.
But if they are not using the most appropriate, accurate information, they aren’t going to gain the best possible results. Will they eliminate (or at least minimize) their bottlenecks? Possibly… Maybe even probably. To use an old-school expression, even a blind pig finds an acorn sometimes.
Our goal — and what we try to help our clients achieve — is to ensure they are identifying, applying, organizing and visualizing the most targeted metrics to deliver the insight they need. Only then will they experience the most significant improvement in their software delivery cycles — and their software delivery value streams. By using the right information, they can also find and remove waste, and affect meaningful digital transformation.
