As much as I love visualization as a technique that gives pretty much any team handful of quick wins, I do consider limiting work in progress the bit that makes or breaks team’s long-term ability to improve. Introducing, fine tuning and maintaining WIP limits is arguably the most difficult part of Kanban implementation, yet the one that pays of big time in a longer run.

Shouldn’t limiting WIP be a no-brainer then?

No, not really.

Introducing work in progress limits is an investment. A long-term one. If a team isn’t ready to make long-term commitment to limit WIP it may not be their time yet. I mean, would you expect that a pretty much chaotic team would understand their process, let alone shape the process using WIP limits? They have quite a few prerequisite steps to make so let them start with that.

OK, but this is the case of teams I often dub immature. But then there are teams that I’m working with and that most definitely are mature enough and we still don’t introduce WIP limits.

Why?

Introducing work in progress limits is an investment. A long-term one. Have I already said that? Oh… Anyway, if we are talking about sort of temporary team working on short-term arrangements investment into making WIP limits work may not be worthwhile.

Let me give you an example. One of my recent project lasted 7 weeks, including first couple of weeks to get things running. Over the course of the project team setup has changed twice. Our environment was far from stability.

Instead of setting up explicit WIP limits we just paid attention to what was happening on the board and were reacting whenever needed, using a couple rules of thumbs:

• Whatever is closer to completion (further down the flow) it has priority over stuff that is on earlier stages.

• We finish what we’ve started before moving on to another task, unless we encounter a blocker.

Thanks to that we naturally limited work in progress and context switching despite lack of work in progress limits. Probably it wasn’t that strict and aggressive as it would be with explicit WIP limits, but I still think we’ve done decent job.

The interesting thing is that I doubt we’d be able to fine-tune the WIP limits before the end of the project, even knowing everything we know once we are done. The situation was evolving very rapidly; bottlenecks were in 4 different places throughout these few weeks. We’ve made a couple of gut calls deciding who should do what, like developers helping with testing or design. In fact, we didn’t need explicit WIP limits to make these calls, although definitely understanding how the work was done was a crucial bit.

If the project was supposed to last a few more weeks we would already have WIP limits on our board. But now the situation has changed; people are working in different setup, so limiting work in progress has to start from scratch.

There are two lessons in the story. One is about WIP limits – they are a long-term investment and every team adopting WIP limits should understand that before they start. Another one is that even if you don’t have explicit WIP limits understanding how the work is done and reducing how much work is started helps. In some way it is limiting work in progress too.

You don’t have to use fancy techniques to limit WIP. As I often repeat: read the board from right to left and start with the stuff that is more to the right. To be precise, this should be: read the board from where the flow ends to where the flow starts, as there are many non-standard board designs, but the idea is basically the same.

You don’t have to work hard to start more stuff – it happens almost without any conscious effort. You have to work hard to finish more stuff. And this is what WIP limits help you with.