Is it a fallacy to use Little's Law to prove that you need WIP limits in Kanban?

Question

I have heard the argument that Little's Law proves that you should limit the work in process in your Kanban columns, because the more work that arrives, the longer it will take to move through the system.

Is this an accurate conclusion? If I have N items of work in the backlog, they all need to flow to "Done". So if I limit WIP to n, that will ensure that I am finishing the n items faster, but it also ensures that I have more work (N-n) left to do. So I am not convinced by the Little's Law argument.

What am I missing?

Answer 1

Littles law claims that reducing your WIP will reduce your cycle time. It doesn't claim that reducing the cycle time for individual tasks will reduce the overall time to complete a project.

There's plenty of information online about the advantages of low cycle time and WIP. The main two are:

• Reduced multitasking tends to lead to faster and higher quality work
• Low cycle time gives you faster feedback and generally makes your team more responsive

Any drop in project completion time comes from secondary benefits like these.

Answer 2

In the page you provided in your comment, there is a link to an article about this that I think explains it pretty well.

There's a pretty good example that I think helps to understand the basic concept:

Both tanks have the same amount of water arriving and leaving so the level doesn't change on either. The level of the tank represents the WIP limit.

So to calculate the average time a bit of water spends in the tank, you simply divide the level by the throughput rate. For the left tank that: 5/2 = 2.5 hrs. for the right tank that's 20/2 = 10 hrs. This assumes that the throughput is independent of the level. It's a little outside of the question you are asking but I think the author makes an important point:

In a software development context, I immediately thought about how context switching, if not managed (with workflow policies) as WIP increased, could make it difficult to keep Throughput constant.

To create my own analogy, let's say you are running a passenger train system and you have 5 turnstiles that can handle 10 people per minute. The station is experiencing backups at the turnstiles so you add 5 more turnstiles. Problem solved, right? Not necessarily. Assume the trains can handle a fixed capacity of 250 people every 5 minutes. Now you can allow 500 people into the station in 5 minutes. But only half of them can get on a train in that 5 minutes. 250 of those people are now just waiting inside the station instead of outside. This means that these people are now jockeying to get onto the trains. The ensuing chaos slows down the rate at which the trains are leaving the station and slows down the overall throughput of passengers.