Why We Still Can’t Control WIP (Even When Everyone “Knows Better”)

TL;DR (AI-powered): We still struggle with WIP not because the math is unclear (AAABBBCCC is faster than interleaving), but because organizations reward the feeling of progress that comes from starting things, 100% utilization, and later heroics. The real work is changing the (often tacit) incentives: make work visible at every level that matters, then deliberately limit WIP where you actually want better lead times.

Maarten Dalmijn (whose Substack I recommend) recently wrote a great piece on controlling WIP (work in progress), relating it to the contrast between managing a controllable pain now and having to deal with an uncontrollable pain later. I really like that framing and the tying to roadmap choices and attempting to please too many at the same time – and risking frustrating them all, really, in the end.

Someone made a comment about it along the lines of “do we really still have to explain that doing AAABBBCCC is faster than ABCABCABC? – Shouldn’t we all know that?”. The argument is sound, since in the end everyone will probably get their thing in less total time spent when not doing things in parallel (due to switching context, and things like that).

My reaction to that was the following statement:

I am afraid we still have to (in my experience). And even drawing sometimes is not enough. The sense of progress for starting stuff is too much of an incentive in some places.

That sparked the idea to further elaborate on deeper aspects of managing WIP, the challenges and the incentives that make what is obvious to many of us to still be too often counterintuitive in organizations.

So here we are. Let’s call it…

In the first several paragraphs above, I already alluded to two reasons. No one wants to be left out or at least not behind, when roadmap sequencing choices are made (that was the core of Maarten’s piece). Plus there are incentives to start new work – maybe because those are moments that are even celebrated and there’s a feeling of assumed accomplishment just because we finally got started.

But then reality hits, and things start to move so slowly and nearly never get really done (or when they do, it feels like “pulling teeth”).

I feel that there’s a common thread there though. That ultimately both reasons boil down to the same kind of dysfunction, which can be thought about as an overreliance on the grinding, of getting a sense of progress and accomplishment just because something has been prioritized and somehow put in motion, that we can keep talking about it as something which is going on.

But then reality hits again, and chances are we are not even fully aware of what it might practically mean. That at best, “cans are being kicked down the road”; at worst, no real progress has been made (despite the fact that technically there has been a bit of focus put on each given item).

A slightly different version of that pattern happens when pretty much the worst thing that can happen in a given context is perceived as not being busy. That fallacy of the 100% utilization as something real, instead of what it really is – a recipe for long, very, way too long lead times.

When in reality having some slack is the way that a complex system can adapt to and accommodate changes in circumstances.

And because of that, sometimes the best thing we can do is not to be busy. That a pause might as well be what it takes to get to a real breakthrough to finally wrap something up – or at least make some real progress shortly.

Circling back to the sort of flabbergasted comment of “shouldn’t we all know better by now?”, there’s another pattern I observe, which is the fact that in some contexts not enough emphasis is put on the ability to get 3 things in a nicely paced and faster way (thus allowing for better managing risks of delivery), when the alternative is to get the same 3 things in roughly the same total lead time, as a bigger batch. That’s typical for contexts in which not enough progress has been made toward real continuous delivery and modernized ways to deliver and deploy software, and so many constraints are put in place on how you go about eventually putting something in production (think separate QA team, change & release management, etc.).

The incentive towards bigger batches, I’m also afraid, although maybe theoretically understood by most people as a risk, still happens to be out there, as a real thing that happens in the real world (in what feels still way too many organizations).

And I honestly could go on and on… Including that chances are in some cases people don’t know any better, and they need to be properly informed about the implications of some of their choices (the little example of AAABBBCCC vs ABCABCABC being a practical way to explain the underlying concept). In a few words – yes, the obvious is worth reiterating if it matters.

But I think you probably got the gist of where I am going with this. That, ultimately, problems with controlling WIP are just the signal, the symptom, and how they come about relates to incentives in place (often tacitly, it’s not like they are written rules or anything like that necessarily) to the system of how work gets done.

And the real question – what’s most worth talking about at least – is not even understanding why those incentives are in place (people will kind of intuitively already know that), but how can you change those?

That’s where real guidance and pragmatism towards changing things for the better lives. And to me, it all starts with two moves:

• Make work visible – but here’s the real trick: at all levels that matter. This is often missed and there’s a bias towards only looking at it tactically, what it means to a given team. When often that’s just the cascading effect of earlier and higher level commitments towards too many goals, initiatives, or whatever those other level chunks of work mean in a context.

• Controlling WIP at all levels, but definitely at the level you want to see an improvement – obviously ideally WIP is controlled at all levels, but if we are to make a deliberate choice of where to focus on, then that’s got to be linked to where we want to see a change. So if an organization struggles with lead time of key initiatives, then it has to better control (and probably limit) how many of those can happen in parallel.

Yes, this can be super-hard, particularly the real lever which is the item #2 in my list. As even Maarten Dalmijn highlighted, you first have to get to grips with wanting to accept a controllable pain (to have those hard conversations earlier) – when often the incentive is just to let things play out and see how things go. That uncontrollable pain later that Maarten talked about might as well be an accepted status quo, and really not that painfully perceived. On the contrary, dealing with that later nurtures heroics and some people will shine in those moments – while smooth execution is just assumed and oftentimes not sufficiently valued.

I believe that, in the end, a lot is “said” (or made apparent) about an organization’s maturity by looking at how things like that are dealt with. What are the incentives in place and do they really imply real problems when things go sideways? Or on the contrary, those are the moments in which real opportunities for showing off and even to finally get that promotion emerge.

If that’s the case, then I am once more afraid, that’s just yet another example of a system perfectly getting the results it has been designed (for as tacitly and even unintendedly) to get.

By Rodrigo Sperb, feel free to connect, I’m happy to engage and interact. I’m passionate about leading to achieve better outcomes with better ways of working. How can I help you?