WIP limits

In a previous blog post I mentioned that we are in a transition from Scrum to Kanban. Or to be more precise, we have been using Kanban for almost a year, but some of the ”Scrum thinking” is still present in our teams. This doesn’t necessarily have to be a bad thing, but one thing we are really struggling with, is putting limits on WIP (work in process).

””Kanban

Can you see, there is something missing in the picture above?

Yes, you are correct, there are no explicit WIP limits present. Putting limits on work in process is essential to achieve flow through your work process and it also ”high-lights” problems that are candidates to be fixed in the name of kaizen (continuous improvements to your process). The WIP limits were there initially, but the teams didn’t see ”the meaning” with them, and removed them (after all, the teams are autonomous). In trying to put the WIP limit ”back” on the Kanban boards, I seek help from some fellows in the Kanban community. Their answers to my question ”How do you get the teams to use WIP limits?” are found below.

Mike Burrows

Mike seems to be a really nice guy and he is also the author of ”Kanban from the Inside”, find my review of this book here.

I tend to approach the question of limits rather indirectly, and (as you’ll know from my book) I’m interested in more than just column limits, being open to limiting WIP in multiple, cross-cutting ways. Tips?

1) I tend to start from the right hand side of the board, looking at the flow of work through (say) validation, deployment, acceptance etc. Not much point in optimizing the flow through development if the work is only going to pile up somewhere else.

2) I’m careful not to celebrate partially-done work (eg in status reports) and to report cycle times that go beyond development.

3) I like to organize work horizontally also and to explore the allocation of effort across those. In my current situation I’m seeing an interesting difference in performance between two workstreams that could be explained by a lack of discipline with regard to WIP.

Marcus Hammarberg

Marcus has helped us a lot. We are even reading the book that he co-authored, ”Kanban in Action”, as a book circle at work. I’ve also made a review of this book.

Hmm, I’ve seen this myself also. I think the most important thing is not to enforce anything: ”DO LIKE THIS! NOW!! This will only lead to alienation and the team will not feel that they ’own’ their Kanban board.

Ask the team – this is simplest, and hardest way; why is it that we always have more things to do than our WIP limit states? Is it too low? Why? I think it is also important to understand that WIP limits is not a law or a ”correct number”. It is a tool to find improvements. Breaching a WIP limit shall trigger a discussion; ”fine we are beaching the WIP limit now, but we do it on purpose”. Some teams that I heard about had a mini-retrospective each time it happened.

Summary

So how did we actually solve the problem? I leave you with a ”cliff hanger” for next week, when I present our approach in limiting WIP 🙂

All the best,
 Tomas from TheAgileist

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s