≡ Menu
Pawel Brodzinski on Software Project Management

Why I Don’t Limit WIP (On Occasions)

Why I Don’t Limit WIP (On Occasions) post image

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.


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.

in: kanban, team management

1 comment… add one

  • paul mahoney March 13, 2013, 10:25 am

    IMO limiting WIP has both short-term and long-term goals and commitments from both the team and the surrounding organization. The organization needs to make a commitment to limit WIP in order to sustain the long-term health of the team(s), while the team need to make both short and long term commitments to limit its WIP. The organization can have profound impact (both good and bad) on teams if the WIP level is not managed appropriately, it the team no good if it constantly has an inbound queue that is constantly over-flowing. There should be a fine balance practiced to ensure the teams are loaded but never can see the light of day, but there also needs to be some tension to add to the teams sense of urgency.
    The teams also need to manage WIP movement within its own eco-system, they need to ensure there are no long-term WIP bubbles and yet not let the WIP run dry leaving people waiting. This also is a balancing act that will take time and experience for the team to grasp and manage.
    So in the end at times WIP will need to be manage well and at other times, such as for learning, the WIP should flow in like chaos and let everyone watch and learn.

Leave a Comment