The lead time plays an important role in the Kanban method and yet the Kanban community is working with different definitions. We agree that the lead time is a time interval, but when we talk about where it starts and where it ends, the answer is almost always “it depends” or “we measure it differently”. According to the latest definition, the lead time is the time a work item spends between the infinite queues. For example between the ready to start and the ready to deliver queues. I believe that this definition is dangerous for two reasons. First, it doesn’t consider the waiting time in the infinite queues which causes most our problems in the software industry, because our forecasts and predictions don’t count with it, and therefore it is inaccurate. Second, the Kanban method should work in any business environment, and the infinite queue makes sense only in a software context. If you have doubts, imagine a waiting room in a hospital with an infinite number of waiting patients in it. So, I’ve started to work with a completely different definition: the lead time is the time the customer must wait to get what she asked for.
Previously I was working with three different definitions of where the lead time starts:
According to the first definition, it starts when the organisation gets an idea from the customer. So, the lead time contains the time period of uncertainty when the organisation hesitates to make a commitment or the customer is not really sure if she really wants something or not. Imagine that you want to buy something, but you’re not really sure about the colour, and you are thinking about it on your way to the shop. By following this definition of lead time, the company’s lead time would contain the time period while you are thinking about the colour you want, but what can a shop do in order to shorten this time? Not too much, actually.
The second definition says the lead time starts when the idea leaves the idea cloud and gets into the ready to start queue. This definition is almost accurate, but we still add some unnecessary time to the lead time. We tend to fill up the queue with promises and we know that a promise is not a commitment. So the idea - now work item - stays there until from a promise it becomes a commitment. Using the previous example, it looks like this: you finally know the colour you want, but the shop doesn’t have any, so it makes you a promise that they’ll call the central distribution and get some information about the next shipment, and you should call them the next day. This one day is still not on the shop, because they cannot really do anything about it. Sure, they can push the central to get it sooner, but the shop hasn’t made a commitment on the shipment. It made a promise to get you information.
The third definition starts the lead time when a work item leaves the ready to start queue (when people start working on it). This definition doesn’t consider the important time between commitment and starting to work on the item. Based on my experience, most of the projects fail because the project managers start taking the project seriously when it starts, but the customer does so only when the commitment has been made. Let’s get back to the shop example. You go into the shop, wait there for 10 minutes and then get served, which takes 3 minutes. According to this definition the shop’s lead time is 3 minutes, but when you get home, you’ll tell your spouse or friend that you’ve spent 13 minutes in that shop and not 3 minutes. Do you feel the difference?
Following the logic from above the lead time doesn’t end when the work item is done. It ends when the customer has it in her hands. If you enter the shop and you can see your desired item, but you have to wait 10 minutes to get it, you’ll add this 10 minutes to their lead time.
The diagram below shows how the lead time should be calculated:
It has three important parts. The first (I) and and last (III) parts are practically waiting times. Either it waits to be started, or it waits to be delivered. The middle part (II) is when the work item is being worked on. Following the shop example, the commitment is made when the shop lets you in and is ready to serve you (it is open). After that you wait in a queue to be served (I), and when you actually reach the counter you can state your request and the shop assistant does his thing (II) and gives you what you want. Finally you leave the shop (III). The shop has full control over each phase (I-III), and the owners or managers can optimise these. For example, have two shop assistants and two on-demand queues. This will reduce the time spent waiting. The shop can reduce muda waste and make the “shop assistant does his thing” phase shorter. And finally, the shop can have a better layout that lets people leave the shop faster.
The situation is very similar in the software industry. We shouldn’t commit until we really have to (see real options), and we should be aware of the waiting time between commitment and start (I), and make it shorter. We can reduce muda during the development phase (II) with various Lean practices, and finally we can create solutions that deliver finished work items faster to customers (III), for example with continuous delivery.
comments powered by Disqus