Product Development involves tough choices and trade-offs. Here’s a typical one: what would you choose to optimise for?
1. Predictability (“on time, on budget”)
2. Throughput (Storypoints or maybe # of stories)
3. Speed (cycletime from idea to live)
Of these three, a lot of organisations have a strong bias that optimises for predictability. Not only is that what they often say they want, but projects as a construct actively encourages that, and often there are incentives that push you strongly into that space. We’ve probably all heard “On time, on budget” as the desired outcome. There’s only one problem with that…
“On time, on budget” is a lie
Product Development is complex, and this is one of those “false friends”. Things that sound good and sensible in theory, but when you try to put that into action it melts, or worse blows up in your face. The inconvenient truth is that if you focus on predictability, then your ability to predict tends to gets predictably worse.
The natural inclination is to spend more time up-front doing deep analysis. You spend longer on requirements gathering, you spend longer digging into the details. And you analyse how long you think each piece of the puzzle is going to take.
Sadly, none of that really gives you much certainty. In the complex space the doing is always different to how you thought it was going to go. This is not a manufacturing line. It’s not a small construction project, like putting in a pool or building a garage. We’ve never done this thing before. And along the way you always discover some complexity that you couldn’t have predicted. You want a crystal ball, but that’s not actually possible. It’s a fairly tale.
Good Project Managers know this. And the only way they can alleviate the problem is to add some of the magical fairy dust that we call “contingency”. If your organisation does manage to achieve the magical “on time, on budget” then you either have a fairly simple/obvious set of steps that are very well understood and very few ways it can go wrong. You probably had a project manager who hid a load of flex into the plan by doubling or even tripling estimates, and then they added a bunch of contingency on top of that.
Doing all this up front work isn’t free. And it leads to really big batches. When combined with sequential development (requirements, then design, then development, then testing, then shipping) you’re highly likely to end up with a lot of corners being cut. That’s how it came in “on time, on budget”. Those corners tend to be the easiest ones to hide (things like testing, security, refactoring for scale and easier maintainability, observability) – and all that will surely come back to bite you down the road. Bad idea.
Throughput/Velocity is good though, right?
If you focus on throughput, you’re likely to get a lot of something — but sadly, what you’ll probably get is mostly vanity metrics. It may feel good for a while, but it’s not likely to move the metrics that actually matter.
Focusing on maximising throughput incentivises 100% utilisation. You starting as many things as you can manage, you tend to see excess work-in-progress – lots of things being worked on in parallel has got to be a way of improving throughput, right? If anyone is waiting on anything, the best thing to do is obviously put that in the waiting pile and pick up the next thing. 100% utilisation will surely improve the throughput, right? That’s what our intuition tells us.
Unfortunately, you see this fallacy play out on the freeways most rush hours. Even 70% capacity utilisation leads to congestion collapse and results in a giant traffic jam. The result is usually much, much worse throughput and effectively zero ability to accurately predict time of arrival. Yes, the destination is only 10 kms away, and at a usual average speed of 40 km/h we should be able to get there in 15 mins. But the traffic jam makes that impossible.
And we’re not even getting into the issue of context switching. Putting something down and picking it up again later when it’s unblocked isn’t free. In short, focusing on Throughput leads to lower throughput and worse ability to predict.
One weird trick: focus on speed (cycletime, not velocity)
This seems wrong, but if you focus on speed (cycletime, not velocity) then ALL THREE tend to get better. To reduce cycletime, this requires splitting things into smaller pieces (smaller batch size), not overloading the team (constraining WIP) and systemic improvements to your process to be able to go from “lightbulb to learning” faster.
It drives a focus on automating all of the time-consuming repetitive tasks and eliminating as much of the waiting time in the process as you can. Blockers that show up repetitively get address, waiting for sign-offs, waiting for more information, waiting for environments, waiting for a build, waiting for testing, waiting for a release. Things like regression testing, things like deployments, various checks often done downstream get shifted upstream in the process.
And because the cycletime is faster, so are all of the feedback loops that tell you whether what you’ve built is valuable or not. You’ll more quickly discover that you’ve missed something important, or that your design doesn’t quite address the need, or that users aren’t engaging with the feature. All of the nested feedback loops that drive quality all have to speed up. So quality and value delivered goes up.
You’ll have to reduce WIP, which means your throughput tends to go up as well. There’s less common cause variation in the process, so everything flows more smoothly. There are fewer shocks on the system, much like how we hold back cars on the on-ramps to protect the flow on the freeway itself. A little more waiting before joining the flow means faster travel time overall AND higher throughput. It all sounds too good to be true, but it’s not – this is basic queuing theory.
And lastly, because it’s all flowing more smoothly you can actually predict with a lot higher confidence and accuracy when you’ll arrive at your intended destination.
So, focus on cycletime, and you get higher throughput and better predictability as a side effect. You get all three. Choose wisely!