Lead Time; one of the metrics used in kanban systems. Basically, it represents the time elapsed in a system for a request; from the first commitment point to when the value/outcome is generated/delivered. The time elapsed to make a request done; when someone’s need is met as Mike Burrows (@asplake) puts it.[1][2]

One use of this metric is to see it as a distribution. With the help of lead time distribution, we can determine how probable it is to deliver requests, with a similar class of service/process, within a given time frame. Basically, it helps you to answer the ultimate question we all encounter; when will it be done?

When I talk about using lead time distributions to answer this archaic question, people look at me as if they found a gem in the dirt. It is magic! Mathematics, in particularly statistics, is magic to the untrained eye. Now you can see me, now you don’t.

Also, when I talk about this topic, they look at me as if I am a charlatan. It depends on how you approach the topic and use the words to explain this phenomenon. One must be very careful, when talking about this subject, to not be seen as a fortune teller.

Most of the time these are the first reactions I get, and I adjust accordingly.

There is also a second reaction; when they try to use distributions in the real world for the first time. This writing is about the second reaction.

Let’s have a look at an example scenario; the customer has an urgent request and wants it in a week. It is non-negotiable because the organization needs to meet the government regulations. The service delivery manager (SDM) looks at the lead time distribution and sees that there is a 40% chance of completing the request within the due date.

The Service Delivery Manager (SDM) is frustrated because h/she just got trained in a pragmatic, actionable, evidence-based guidance but can’t apply it. H/She wants to say “You are being unreasonable. There is a 40% chance that this can be done. I can’t do this in the time frame you have given me. The distribution says so! There are a lot of critical requests you have already made last week which are still in progress!” to the customer but simply cannot. 🙂

So, the SDM turns to me and says, “Ha ha, Kanban this muthafakaa!” 🙂

The SDM has mixed the meaning of probabilistic approach with fortune telling. And using the new-found arsenal to say no. This is not the evolutionary way.

When this happens, I try to clarify what we are trying to do in an evolutionary way with the points written below.

1. We are not in the business of fortune telling.
2. The distribution is telling us the probability of delivering an item WITHIN a calendar date or time frame with the current data/situation in hand. The distribution does not tell us that this item will be done on that exact date. That is fortune telling.
3. The distribution might tell us a different story with every new data point/sample gathered.
4. We are not using this probabilistic approach to say no. That causes resistance.
5. We are not trying to change the way we have been working with the customer right then and there. This also causes resistance.
6. We are trying to avoid resistance as much as we can. Be like water.
7. We are trying to create a feedback loop.
8. We are trying to shift the responsibility to upstream as much as they can tolerate.
9. We are trying to make them see the situation as we are seeing, with using scientific models. Not just words but with proof.

After this I help them on how to respond to the customer without saying NO but letting them know the risks that are involved to make this request happen in the time frame that they request. Letting them know of possible actions that needs to be taken to make the requested due date more probable. Maybe suggesting that the previous requests will be put on hold and delayed.

This way the customer will know from the start that when they ask for the request a week later there is a big chance that they will hear “it is not done, yet.” No surprises. Empathy and trust starts to build up. And next time the customer will be more willing to listen or help on the situation. Because responsibility has been shifted to them.

Rome is not built in one day. And if it would have built in one day there surely be a resistance. 🙂

When applying Kanban principles and practices you cannot expect your outer world to obey the new rules. That simply cannot happen without resistance or tears. You need to prove them something first and prove it with facts so that you can gain their trust. After this you can negotiate new rules and promise them the outcomes they will see if the new policies hold.

Pursue the evolutionary way. Be like water. Be humane and kind. If you can’t visualize your situation and build feedback loops to let others see, you can’t expect them to sympathize with you.

This is how the decision-making framework starts to build. This is how one starts managing flow. This is how one can build empathy and trust using metrics in an evolutionary way.