One year ago I wrote a post talking about WIP limit and its importance. At the time, it was a case study and an introduction to the subject. However, after working on more projects and meeting different people, I saw that, maybe, you don’t need it.

Introduction

When we use WIP limit, we limit the number of concurrent tasks. It could be a limit to each column of a Kanban Board; it could be a limit to the whole system; or even a limit to a set of steps of the process.

The idea behind limiting the work in progress is to work side-by-side with Little’s Law and try to improve the flow of the system, diminishing the lead time (LT) of a work item. And that works like a charm for machines. For software development? The relationship between WIP, LT and throughput is not that straightforward.

People are different

When we have a chain of machines linked together, in which the output from one feeds the input of other, everything is easier to predict. Now, imagine a situation in which:

• Items entering the first machine are not always the same size. And the machines don’t follow a linear relationship between size and time to complete a task.
• Each machine can, unpredictably, change its behavior. One week, it may receive an input of size x and generate its outcome in 1 hour. In another week, it will, unpredictably, take 3 hours to produce the same result.

Things start to get tricky, right?

WIP Saturation Chart

From my experience, some readings and even the way I work, I saw that different people work best with different workloads. I believe that a chart of WIP by the throughput of a person follow something like this:

This chart was taken from https://www.infoq.com/articles/how-kanban-works.

Some people work best with more than one task at a time. For different reasons. They might get unmotivated with few responsibilities, or it might be easy for them to rapidly change focus between tasks, for example. On the other hand, other people have a really difficult time changing focus and handling many tasks at once.

Other than depending on the person, it also depends on the project: it might involve third-parties that regularly block their work, it might have a testing process that takes weeks or months to finish, etc.

So, how can we come up with a single number that will magically fit all those curves under the same process? You can’t. But that doesn’t mean you shouldn’t.

So what? Should I just go crazy and forget limits?

As I said, it is just impossible to get a number that limits the work of everyone in an optimal manner. But that doesn’t mean you shouldn’t use one. I see, until the time of this post, two options for two different contexts:

1. You have someone looking at your process. If you have a Project Manager, an Agile Coach, a Scrum Master or other person that takes care of your process, you don’t need WIP limits. You need WIP management. This person can better understand how each person works and alert people to the amount of WIP according to each individual necessity as well as the type of project. I’d only use WIP Limits here to give process ownership to the rest of the team. This means that the person looking at the process would be actually temporary.
2. You don’t have a process guru. In this case, limiting the WIP with numbers and trying to tune it with time will give you a better process. It will not give you the optimal outcome, but it will unquestionably give you a better result.

Conclusion

WIP limit works. It will improve your process. But it is not a silver-bullet (I feel like a parrot repeating this). Look at your context (people + project) and use whatever delivers a better outcome.

What do you think? Do you believe in WIP Limits or not? Leave your comments below!