Throughput Transformation Tactic
A botched workshop taught me about focus. Here’s why.
Catching up to Sam, I squeaked “So what did you think of my value stream mapping workshop?”
“What was the goal?”, Sam responded.
“To improve the speed and quality of software delivery, so we can achieve our objective of rolling out our product in Europe by 2025.”
“What’s the next step?”
“Well, we identified over 20 areas of improvement to reduce wait time and rework in each team.”
Sam stopped by his favourite whiteboard, conveniently located next to a coffee machine. “How long do you think those improvements will take?”
“Teams are busy. This workshop was 3 weeks in the making, so maybe a few months?”
Coffee in one hand and board marker in the other, Sam started scribbling. “The teams involved were Design, Development, Testing, and Operations, right? Can any one of these teams ship working product in isolation?”
“Well no, each of them contribute to the end product.”
“So, they’re interdependent. Work must proceed in sequence from one team to the next to create a shippable product.” Sam pointed to his diagram. “Let’s start with the first team - if we helped Design do more in less time, what would be the impact?”.
“Well, that would be great!”
“Are you sure?” asked Sam, raising an eyebrow. “What would happen downstream?”
“Oh. Work would probably pile up in front of the next team - Development.”
“What about if we help the next team, Development?”, quizzed Sam.
“Ah, the same. Work would pile up in front of Testing.”
“So, helping any one team seems to only cause work to pile up with the next team in the sequence. What have we missed?”
“Can’t we just help all teams?”, I queried.
“You’ve said that’ll take months. Let’s be lazy. Do all teams complete work at the same rate?”
“Oh, no - Testing are the most capacity constrained. They have the most work waiting on them.”
“So, what happens if we help any team other than Testing?”
“Oh! We’d only be causing more work to pile up with Testing! We need to help Testing!”
“Yes, they’re our VIPs. We can’t waste their time”, responded Sam as he scribbled a pipe onto his diagram. “Testing is the bottleneck. The rate of testing dictates the rate of the whole of software delivery. How many of your 20 improvements focused on improving our use of our Testing team’s capacity?”
“Um, just two.”
“Seems you have your next steps.”
The takeaway? Improvement anywhere other than the bottleneck will only cause work to pile up more quickly.
The takeaway? Improvement anywhere other than the bottleneck will only cause work to pile up more quickly.
