Lead Time — a misleading term
Cycle Time is still the better name
There is value in reading several books about the same topic. Even when I do not learn the same amount as with the first book, reading the same concepts presented another way can serve to refresh my knowledge and deepen my understanding. And every now and then, I finally get a point that I was struggling with before.
So it happened recently with Making Work Visible — Exposing Time Theft to Optimize Work & Flow (2nd edition) by Dominica DeGrandis. (If you are curious about the book, learn more in my material collection.)
One thing I could not wrap my head around was Lead Time — more specifically, why I don’t like it. The definition I keep reading sounds very good: Lead Time as the time between a customer requesting something and the order being delivered. As a comparison, Cycle Time measures the time between when a work item was started and when it was finished.
Dominica DeGrandis uses a pizzeria as an example. It seems obvious that in this case, Cycle Time is only part of Lead Time. Orders might be stacking up while they are not being worked on, Lead Time increasing while the Cycle Time has not even started. The customer will not care about Cycle Time in this case; Lead Time is what counts.
Lead Time sounds more complete. This avoids local optimization, e.g. getting faster at preparing the pizzas while the actual delivery becomes slower.
So why I was I sticking to Cycle Time? In hindsight, it is so simple. Most of us do not work like this. A pizza order is about a known product with some potential variations. It is not about “I was not even aware that I was hungry until you presented me a solution”. An order means “I really want it”. Compare this to my article about the Definition of Ready: Imagine someone ordering a pizza and then not being at home for two weeks. Sounds ridiculous for a pizza; can totally happen with stakeholders of IT products requesting an “urgent feature”! Moreover, items can have different sources. It is even dangerous to just do whatever the customer wants.
In short, IT products are not like a pizza. Case could be closed. But there is more. Lead Time can be gamed: When talking to your customers, you note their requests but ask them to file them later, so that the Lead Time looks better. Or you restrict access to the IT system handling requests. In other words, Lead Time as a leading metric creates wrong incentives. Imagine you know about a change in legislation that will come a few years ahead but you intentionally do not capture it to not create a Lead Time of several years. As a result, the topic only comes up last-minute and then creates a lot of unnecessary urgency. This is a typical case of what my colleague David Daly calls an “artificial fire” in his book “Better Agile”.
And finally, Lead Time in this form is push-based. If every order placed means an item is started, good luck balancing arrival and departure rate! This does not sounds realistic for a pull-based approach in software development.
So what to do instead? The most practical, unideological solution comes from the people around the Kanban Guide: “Lead Time” (just like “Flow Time”) is just a fancy word for one specific Cycle Time. Do not get confused by terms. Define several start and finished points and see what works.
Drunk Agile: Episode 32 Cycle Time vs Lead Time
“Do not care that much about how you call that time.” This is another case of William Shakespeare’s wisdom about the futility of relabeling.
Things are as they are. It does not matter how you call them.
Wait a moment, how can they be the same? Didn’t I say earlier that Cycle Time was about departure rates and Lead Time about arrival rates? In the pizzeria example, yes. Elsewhere, it depends on what we want to model and what our assumptions are. (Thanks again, Dan Vacanti!) Flow Metrics can be expressed both in arrival and in departure rates.
Get Gunnar R. Fischer’s stories in your inbox
Join Medium for free to get updates from this writer.
The Lead Time definition “from order to delivery” is actually not so complete. Compare Jurgen Appelo’s thoughts about Value Streams where he expands this to “from signal to experience”. How much time does a pizzeria owner take to see a shift in consumer preferences and adjust the menu? How long does it take to get the customer interested in ordering a pizza? How is the experience after it has been delivered? How fast does the pizzeria crew learn from customer reactions?
The Evidence-Based Management Guide (EBM Guide) mentions several several time-based metrics, among others Time-To-Learn (T2L) as proposed by Peter Koning. I would also inspect “time to feedback incorporated”.
Lead Time for Changes, one of the four DORA metrics in DevOps, is actually not a Lead Time in the above sense. It measures the time from code committed to code successfully running in production. This could be gamed in similar ways as already described. Plus, even if a product is live, customers still might need to be configured for it.
In case of doubt, I would go with several Cycle Times and distinguish which variant is meant in which case. The Cycle Time formerly known as Lead Time can be used as a secondary metric in some cases: What portion of the larger Cycle Time does our narrower Cycle Time cover? This can serve as a signal: Do we want to adjust our Definition of Workflow to include upstream or downstream steps?
Compare this to a famous picture used in a talk by Klaus Leopold. The larger Cycle Time can be good to spot inter-team problems and things moving slowly overall. However, as a single metric, it could also serve to hide local problems.
Klaus Leopold: Why Agile Teams Have Nothing To Do With Business Agility @ LKCE17
Klaus Leopold: Warum agile Teams nichts mit Business Agilität zu tun haben @ LKCE17
Long story short: Be smarter than me. Do not get hooked up about an artificial distinction between Lead Time and Cycle Time. Use Cycle Time(s) and be clear about your definition(s).
Queen: Bicycle Race
