Little's Law - Lean Software Development - 3

Again, the Poppendieck's are coming to Charlotte (see here), so this is a continuation of posts on ideas they talk about.

This one is a particular favorite of mine: Little's Law. (No, not me.) This is from John Little, a professor at MIT's Sloan School, and it's in regard to queuing theory.

So, we believe (and in fact long experience has shown) that we should satisfy the customer as quickly as possible. Reduce end-to-end cycle time. Thus, for example, we use value stream mapping in Lean.

So, we have a black box (the business system/process) and we want things to go through that box as quickly as possible. One way of looking at this is queuing theory. Every time you stand in line at a grocery store or a bank or an airport, you are hoping that someone there has studied and implemented queuing theory.

Now, I am not going into queuing theory a lot. Let's just discuss Little's Law. It states something that is actually obvious common sense (and he proved it mathematically): the average time is takes a thing (say, a person) to go through the black box is equal to the number of items in process divided by the average completion rate per item (when the system is running well).

In other words, if there are 10 people in line, and each of two tellers can serve one person every 5 minutes, you can expect the last two people to be "completed" after 25 minutes. And, if people arrive in the queue at 2 per five minutes, you can expect the average completion time for the day to approach 25 minutes for all customers.

So what? How do I use this in my project?

Well, from this we deduce...put fewer things in process. To get stories done quickly, only work on one or two stories at a time. Don't make a big backlog of stories, so that you can release more quickly. If you want your projects completed more quickly, start fewer of them.

These are simple statements, and in practice need some modification (eg, consideration of all the other factors in play).

One of the bigger ones is the cost for people doing task-switching. This is generally far larger than generally recognized (eg, effort and motivation and FUD). These costs for human systems (eg, a SW dev team) urges us even more to put fewer things in process.

There is generally minimal cost associated with implementing Little's Law, except...for the cost of changing the way your colleagues look at work and work-in-process. An important cost, but worth it.