Why I don't use Cycle Time in Kanban

Why I don't use cycle time in Kanban from Andy Carmichael

These slides were produced in response to a request for a brief summary of the terms I use for describing flow systems, particularly in a Kanban context. Along the same theme also see The difference between Cycle Time and Lead Time, More Musings on Little's Law, Visual explanation of Kanban terms and In search of unambiguous terminology for Flow systems.

What is there to be afraid of?

What is worthy of our fear? Is Death? Surely not. He who lives will die, and such inevitability must be respected and known, yet not cause dread. No more fear taxes, since he who earns can scarce keep it all, can he, any more than he can take it with him? For what purpose would you keep it all? I grant you death and taxes should be avoided - where it's possible to do so with honesty and honour. But they are not worthy of our fear.

Maybe boredom is a more suitable object. To live an uninteresting life is both eminently possible and profoundly fearful. Don't you have a mind though, and doesn't it engender imagination? And is it beyond that imagination to find an action, project or enterprise that could engage you in some means of improving your own or your fellow's lot? Boredom is not worthy of fear, since it is easily remedied.

Yet I think there is an entity worthy of fear, fear true and cold. It is waste... the waste of human potential. Such waste inhabits every corner of life where ideas spring up and are swallowed, spontaneously springing to life and dying like fundamental particles separating and colliding undetectably in the depths of space. Waste of human potential is omnipresent. It occurs in places of learning, and places of work, in families and in churches, in friendships and in war. It steals not only from those whose potential is untapped but from their communities, their

 relationships and indeed all society.


Fear this waste. Yes. Fear it and fight it.

More Musings on Little's Law

My previous posting about why not  to use Cycle Time in Kanban resulted in some interesting discussions, and I'm grateful to +Steve Tendon for pointing me in the direction of this paper [1] by John D.C. Little and Stephen C. Graves which gives some very helpful historical background into the derivation of Little's Law, its applicability and some of the terminology used.

From Little and Graves (2008)

Little's own formulation of the "law" was as follows:

L=λW

where

L = average number of items in the queuing system,
(equivalent to WIP in Kanban terminology)

W = average waiting time in the system for an item,
(equivalent to System Lead Time)

λ = average number of items arriving per unit time
(equivalent to Delivery Rate, assuming "stationarity")

With Kanban preferred terms we can see this maps to:

WIP =  Delivery Rate * Lead Time
or
Delivery Rate = WIP / Lead Time

Little used "waiting time" for the time taken by one unit to traverse the system (W) because his original context was queuing systems. For other applications he suggested Flow Time, which I think is a very useful alternative.

He also notes though that other authors use other terms for W, including cycle time, throughput time, and sojourn time, depending on the context. Yes - cycle time I'm afraid is in that list which is why confusion still abounds. This conflicts with the more generally accepted definition of cycle time in manufacturing, which corresponds to the target rate of working expressed as Takt Time, and is the reciprocal of Delivery Rate. In other words this confusion of terminology is at least as old as the reference Little and Graves cite: Factory Physics by Hopp and Spearman (1st edition:1996).

Useful background, but the message to me is still: "Don't use Cycle Time in Kanban!".


References:

[1] Little, J. D. C and S. C. Graves (2008). Little's Law, pp 81-100, in D. Chhajed and TJ. Lowe (eds.) Building Intuition: Insights From Basic Operations Management Models and Principles. doi: 10.1007/978-0-387 -73699-0, (c) Springer Science + Business Media, LLC http://web.mit.edu/sgraves/www/papers/Little%27s%20Law-Published.pdf

[2] Hopp, W. J. and M. L. Spearman (2000). Factory Physics: Foundations of Manufacturing Management, 2nd (ed.), Irwin McGraw Hill, New York, NY.

The difference between Cycle Time and Lead Time... and why not to use Cycle Time in Kanban

Before addressing the question of which terms you should use in the Kanban method, let me attempt an explanation of the generally accepted meaning of these terms. (We'll come to the question of how generally later!)

Firstly Cycle Time: it is the time between units emerging from a process. You could visualise it like this:

Our system here could be a Development Team say, and the units User Stories (although we would expect to have more variation in this case). Equally it could be a bicycle assembly plant (working not very fast). The Cycle Time here is half a day because the system produces one unit every 0.5 days. Therefore the Delivery Rate (which is Kanban's preferred term for measuring throughput) is 2 units per day.

To understand Lead Time we need to put a marker on one of the items entering the process, and then see how long before that particular item emerges. Like this:

Lead Time is the time taken for one unit to pass through the process. So our Lead Time here is 5 days.

Now before we consider Little's Law, can you look at those 2 pictures and tell me how many units of work there are in progress in the system under study (WIP)?

Scroll down when you've thought about it...






Scrolling...






Still Scrolling...






Nearly there...




Anyone say 10? That wasn't too hard was it? You've just derived a simple application of Little's Law for a regular (and "stationary") process, and you probably found it easier than plugging the numbers into Little's Law itself:

Delivery Rate = WIP / Lead Time

or

WIP = Delivery Rate * Lead Time
WIP = 2 * 5 = 10

So Cycle Time (as defined here) and Lead Time are very different concepts. However there is one important case where they are equal... when there is only one unit in progress in our system (plug WIP=1 into the formula if you doubt this, or change the Lead Time in the example above to 0.5 days and visualise what is happening). Whenever WIP>1, Lead Time will be longer than Cycle Time.

Why not use Cycle Time in Kanban?

Ok so if that's what the terms mean, why shouldn't we use Cycle Time in a Kanban context?

Put simply, because people use different terms to mean the same thing, and - even worse - the same term to mean different things. And the worst confusion is associated with the terms Cycle Time and Lead Time.

There are authoritative sources from well-respected authors that use Cycle Time to mean something different to its common usage in manufacturing circles (the meaning explained above). This inevitably leads to a whole bunch of confusion. This is why a session at the recent "Kanban Leadership Retreat" (#klrat) led by +Dan Brown sought a common policy for use of these terms in Kanban. They proposed a first step which was that the terms recommended by Kanban for use in Little's Law should be Delivery Rate, Lead Time and Work In Progress (WIP). Furthermore it proposed that the use of Cycle Time should be deprecated, and its reciprocal Delivery Rate should be used instead.

I happen to agree and support this proposal, but I also think there is a necessary second step: to understand what Cycle Time is, as defined in manufacturing, so that you can explain why we use Delivery Rate in Kanban instead of this term as the measure of throughput, and also so that you can explain the Kanban terminology to those who wish to use Cycle Time and Lead Time as synonyms... and hopefully persuade them to adopt the agreed Kanban terms instead.

Good luck!

See also: Why I don't use cycle time in Kanban and Glossary Proposal

Notes:

See also: the  list of terms and definitions that you need when measuring flow and efficiency in Kanban, posted previously.

I'm indebted to this Harvard Business School archive from the year 2000 (which uses Professor W. Bruce Chew's glossary) for the clearest explanation of these terms I've seen so far [http://hbswk.hbs.edu/archive/1460.html], also for the discussion of cycle time In Womack and Jones' "Lean Thinking" (1996, 2003),  and for this blog [http://www.isixsigma.com/methodology/lead-time-vs-cycle-time/] from Fang Zhou which also gives a very clear explanation and was my source for the HBS page .

I'm also very grateful to all those from the Kanban community who have put up with my badgering  and whining about this issue over the last few weeks! Their comments have helped me clarify the issue and decide how best I can explain it to my clients.

In accepting Lead Time as the preferred term for the time taken by one unit passing through the system, the Kanban community has to acknowledge some problems, particularly that some people wish to use this term only for the time from customer order to delivery (which is why qualifying this term, e.g. System Lead Time, may be needed). Little himself used "Wait Time" (because his context was queuing systems). However he also suggested the term Flow Time, which is certainly another good candidate for an unambiguous term.