WIP Limits by Conversation

The biggest challenge when applying Kanban on portfolio level is how to introduce WIP limits. Kanban without limiting work in progress will always be shallow. In fact, many would argue (me included) that it is not Kanban at all.

The problem is that typical methods we use to limit work in progress on a portfolio level simply don’t work. Well, of course you can try to limit the number of concurrent projects, but if you’re like a vast majority of companies your projects will vary in their size very, very much. I find 1:200 difference in size between the smallest and the biggest project run by an organization pretty common.

If we wanted to translate this to work we do on a team level we would be talking about having tasks that we finish in anything between half a day and half a year.

It means that you could substitute one of your big ongoing projects with a dozen concurrent small ones and that’s still fine. Except that using a number of projects as a WIP limit doesn’t seem like a good idea anymore.

Limiting work in progress in such an environment has to be contextual. One has to take into consideration size and length of projects, dependencies between them, etc. A different WIP limits will be applicable when portfolio is dominated by medium-to-big endeavors and different will make sense when you’re coping mainly with small projects. In short, to say anything more about sensible WIP limits we have to know the context.

If we discuss the current context, everything that is happening right now, estimated effort needed to complete the new project, available and required capabilities and any other potential projects we can likely say whether we should or should not start the project. This is basically the core of idea called WIP limits by conversation (I credit Klaus Leopold who I learn the term from). With each new project in a backlog we discuss to say whether it fits the implicit WIP limits or not.

It may sound like it’s a lot of work but it isn’t. The most difficult discussions will be around relatively big projects but then, you don’t start such projects every other week, do you? Discussions about small projects may be more frequent but they will be way easier to decide on too. And they won’t be happening so very often either.

A tool that is very handy to support WIP limits by conversation is good visualization. Unless everyone involved has a general idea which teams work on what, what capabilities free teams can offer, what are other commitments, etc. the discussion will be basing on gut feelings. And a gut feel of most CEOs is that the company will cope with every single project… somehow. This is how you end up having 30 people involved in 100+ projects. Not the most effective way of working, right?

I am perfectly aware that the approach seems to be vague, but the general rule is that the more variable the work is the less explicit WIP limits can be.

WIP limits by conversation may also seem fragile. If there is a person who pushes more and more projects into the system lack of explicit rules for limiting work in progress may seem like a weakness. Not necessarily so. Usually visualization is enough to show risks attached to a project that doesn’t fit available capabilities. After all, no wants to start a project that is doomed for failure and will hurt the organization’s reputation.

Of course the conclusion of discussion may be that not starting the project is not an option because of, e.g. relationship with the customer, but then you simply start talking about costs. What other work won’t be done or will be delayed, etc. A format of conversation proves to be very useful on such occasions.

One nice side effect of introducing WIP limits by conversation is that you are encouraged to talk about thing like expected value, cost of delay, estimated effort and probabilities of all of these numbers for all the projects that you start. It usually helps to refrain from projects that don’t make much sense but unless you’d started asking such questions no one would have been aware of the fact.

Another gain is slack time generated on a team level. If you care about not overloading the teams, occasionally they won’t have an ongoing project. This is perfect moment to all sorts of improvement work as well as learning or helping other teams.

My experience is that, despite its vague nature, limiting WIP by conversation works surprisingly well. After all, I don’t know many people that want to make their teams miserable and hurt their organization on purpose.