What’s WIP and why is it so important to limit it ?

Today a short post about what WIP is and why it is so important to limit it.

WIP = Work-in-Progress

WIP means “work in progress”. A more production oriented definition is that WIP are partly finished products that are currently in the production process.

So basically WIP just means something you’ve started and not yet finished. Considering a very simplified process, you’d have a backlog containing products, requirements, ideas on which no work has been done yet, then your WIP which are things taken from the backlog and you’ve worked on and the finished tasks / products.

Limit your WIP

Just like computers we are able to multi-task. Or rather we can task switch. This means we can work a little bit on something and before it’s finished switch to something else. Doing this we do not lose all the hard work done on the previous task. We can switch back once the other task is finished. Or once someone calls and asks about the progress of the first task.

So what’s the problem ? Why should we limit the work in progress.

Well, just like computers or machines, when we move from one task to another we need to switch contexts. This means we to figure out where we were before switching to another task in order to be able to resume this task.

It’s like a robot having to work on two production lines. If it is placed in the middle, it can work on them switching from one line to the other. But it needs to move its arm from one line to the other. It costs time (movement time). And the more it switches the more time is spent on moving and the less time on the actual production lines.

For computers, it’s the same. A computer can process e.g. many database requests in parallel. But each time it switches tasks it costs time to reload the previous context.

OK. So basically, the less we switch contexts the less time is lost and the more productive we are. So why do we switch contexts at all ?

Well, there are two main reasons.

First, let’s consider a very simplistic example:

Let’s assume you start in the morning with a task A which should require about 2 days of your time. Now, you started working on task A, when you get an email saying that you need to take care of tasks B as well and it’d be great if you could finish it until noon (which shouldn’t be a problem since it should take you only 2 hours).

So of course you could decide to first finish task A and then handle task B. But you’d then come back to your colleague 2 days later then expected and nobody would understand why it took you over 2 days to handle a task even my grandma could have finished in half a day. So in some cases, you actually need to have some parallel work in progress… So is it good or is it bad ?

Well, it definitely depends ! This is a classic throughput vs. response time question. It is the same question IT guys have to handle when tuning a system. Is it more important whether the response time is good or is the throughput more important. For example, if you have a system where the user can search for some data in a huge database and wants to get all matching results. Response time might be more important, because the user can already have a look at the first few results if they come fast (even if it means that the rest of the results will take longer, because all other users also get a fast response time). On the other hand throughput might be more important, if the user actually needs to know how many entries where found or if the user needs all entries in order to be able to start with her work.

In most cases, you can’t completely ignore response time just to optimize throughput. In the above example, assuming switching between task A and B costs you about 15 minutes, you’d save 15 minutes by finishing A first before starting to work on B. But I doubt anybody will give you medal for saving these 15 minutes at the price of having a colleague not able to work for 2 days because he was waiting for your output.

On the other hand, if you do not get such emails only once a day but 10 times a day and get the second email before you even finished task B, you’ll keep switching tasks. In this case, you do not sacrifice 15 minutes of your time to improve response time but you sacrifice two and a half hours every day just switching tasks. Also the task which was supposed to take 2 days of work effectively took a whole week, because of the interruptions and task switching.

Now, you understand why multi-tasking is required in many environments but if you do not limit it, you’re production will go south and reach freezing temperatures at around 0%.

Another reason for the WIP is that it is sometimes difficult to prioritize things. Or it is difficult to figure out what the consequences of a delay could be. So you just hope that by finishing everything a little bit late, you won’t get slapped as bad as if you deliver a few things right on time but a few others very late. Who would be mad at you for needing a few more hours to complete something ? It’s definitely not as bad as finishing something 2 days late…

Well the problem here is that you’re probably just so focused on trying the avoid the big slap that you’re not even trying to figure out how to avoid the situation altogether. It’s like knowing there will be banana peals on the floor when you get into the office and coming everyday with a helmet… Maybe it’d make sense to move the cage of the chimpanzee to another location…

That’s what lean is all about. It’s not about avoiding negative consequences. It’s about making the problem apparent (by showing that the WIP limit keeps being exceeded), finding the root cause and improving the process to eradicate the cause.

How much WIP is good?

That’s probably the next question which pops up. The standard definitive answer for such question is: Well… it depends.

Task switching is an issue because you need to get back to the previous context. But it’s of course not as bad if you still approximately remember where you were than if you have to reread that long email, you started writing because you don’t even remember what you were writing about.

There are people who are better at this than others. I guess it’s also something you learn. After working on many customer issues (crashed systems and such) in parallel for a few months, I felt it wasn’t so difficult switching for a short time (to answer a quick question) and come back. Well, after spending a few years doing the opposite i.e. working on topics which were planned in advance and on which I worked for 1 or 2 days in a row without being interrupted, I got back to a position where I had to handle all those customer issues. And it was really difficult in the beginning to be switching tasks again every 5 minutes. Now after a few years, it’s better again but still I find it not so easy to recall what I was doing after shortly switching to another task. The difference is maybe that I’m five years older and my brain starts thinking about getting pensioned…

So it depends on your ability to switch. Basically, nobody can tell you how much is good maximum number of parallel tasks for you. You have to figure it out based on your experience. You can also set some limit and see how it works. Then you can adapt it to a value you feel gives you enough flexibility and still allows you to work in productive way.

Why do I keep exceeding the limit?

So ideally, if you have set a WIP limit of 3, you should not get to the limit and still need to quickly take up an additional task. If you keep exceeding your WIP limit, it can only mean either of these:

  • Your WIP limit is to low (setting it to one does send a clear message but is not that realistic…).
  • Your process needs some fixing and improvement because it keeps driving you back to this place where all know you’ll fail.

If you already have a WIP limit that actually matches what you can do in parallel and still do a good job, you’ll have to perform some root cause analysis. This means it’s time to reflect on the way you and your organization work i.e. your process (drinking a cup of tea or a beer depending on which continent you live). There are many methods to do this in a structured and efficient way. If you feed Google some of these terms, you should be able to get a few good ideas:

  • Five Whys method
  • Pareto principle
  • Fishbone Diagram
  • Change Analysis

2 thoughts on “What’s WIP and why is it so important to limit it ?

  1. nice reading again, thanks.

    as far as I can say, the very important thing is to be transparent in the tasks which I do to the people I’m responsible to and those I work with (team). so that the pain can be spread 🙂
    I believe that transparency removes doubts (or just confirms them :), that’s the dangerous part) and can possibly decrease the pressure and maybe even lower the load. In fact it can push on whoever gives you the tasks, as he/she sees how much stuff you have on your head to distribute/prioritize work in a better way

    1. Yes, transparency is important in agile and lean projects. It’s also the only way to reduce your load. If nobody knows you are overloaded, nobody will try and find a way to reduce the load.

Leave a Reply

Your email address will not be published.