[For the nature of confusion around this terms compare and contrast these: Agile Alliance Glossary; Six Sigma; KanbanTool.com; Lean Glossary.]
The team I'm working with had a toy basket ball goal over their Scrum board... like many cheep toys the rim broke. Someone bought a superior mini goal, it's a nice heavy quarter inch plastic board with a spring loaded rim - not a cheep toy. The team used "Command Strips" to mount it but they didn't hold for long.
The team convinced me there was a correlation between their basketball points on the charts and the teams sprint burndown chart. Not cause and effect, but correlation; have you ever stopped to think what that really means? Could it mean that something in the environment beyond your ability to measure is an actual cause to the effect you desire?
I asked the head person at the site for advice, how could we get the goal mounted in our area? He suggested that we didn't need permission, that the walls of the building were not national treasures - we should just mount it... maybe try some Command Strips. Yes, great minds... but what about getting fired after putting holes in the walls scares one from doing the right thing? How hard is it to explain to the Texas Work Force Commission when they ask why you were fired?
The leader understood that if I asked the building facilities manager that I might get denied - but if he asked for a favor... it would get done. That very day, Mike had the facilities manager looking at the board and the wall (a 15-20 minute conversation). Are you starting the clock? It's Dec 7th, lead time starts when Mike agreed to the team's request.
The team was excited, it looked like their desire was going to be granted. Productive would flourish again.
Over the next few days I would see various people looking up at the wall and down at the basketball goal on the floor. There were about 4 of these meetings each very short and not always the same people. Team members would come up to me afterwards and ask... "are we still getting the goal?"... "when are they going to bring a drill?"... "what's taking so long?"
Running the calendar forward a bit... Today the facilities guy showed up with a ladder and drill. It took about 20 minutes. Basketball goal mounted (Dec 13th) - which clock did you stop? All of the clocks stop when the customer (team) has their product (basketball goal) in production (a game commences).
I choose to think of lead time as the time it takes an agreed upon product or service order to be delivered. In this example that starts when Mike, the dude, agreed to help the team get their goal mounted.
In this situation I want to think of cycle time as the time that people worked to produce the product (mounted goal) - other's might call this process time (see Lean Glossary). And so I estimated the time that each meeting on the court looking at the unmounted goal took, plus the actual time to mount the goal (100 minutes). Technically cycle time is per unit of product - since in the software world we typically measure per story and each story is some what unique - it's not uncommon to drop the per unit aspect of cycle time.
Lead time: Dec 13th minus Dec 7th = 5 work days
Cycle time: hash marks //// (4) one for each meeting at the board to discuss mounting techniques (assume 20 m. each); and about 20 minutes with ladder and drill; total 100 minutes
|Lead Time 5 days; Cycle Time 100 minutes|
This lead to a conversation on the court - under the new goal with a few team members about what we could do with these measurements. How if one's job was to go around and install basketball goals for every team in the building that a cycle time of 100 minutes with a lead time of 5 days might make the customers a bit unhappy. Yet for a one off, unusual once a year sort of request that ratio of 100 minutes to 5 days was not such a bad response time. The customer's were very happy in the end, although waiting for 5 days did make them a bit edgy.
But now what would happen if we measured our software development cycle time and lead time - would our (business) customers be happy? Do we produce a once in a year product? (Well yes - we've yet to do a release.) Do our lead times have similar ratios to cycle time, with very little value add time (process time)?
Well it's January 5th and this example came up in a Scrum Master's Forum meeting. After telling the tale we still did not agree on when to start and stop the two watches for Lead Time and Cycle Time. Maybe this is much harder than I thought. Turns out I'm in the minority of opinions - I'm doing it wrong!
Could you help me figure out why my view point is wrong? Comment below, please.
LeanKit just published an article on this topic - it's very good but might also misinterpret cycle time. I see no 'per unit' in their definition of cycle time. The Lead Time and Cycle Time Debate: When Does the Clock Start? by Tommy Norman.
LeanKit published this excellent explanation of their choices in calculating cycle time within their tool: Kanban Calculations: How to Calculate Cycle Time by Daniel Vacanti.
LeanKit Lead Time Metrics: Why Weekends Matter
Elon Musk turns a tweet into reality in 6 days by Loic Le Meur
The ROI of Multiple Small Releaseshttps://en.wikipedia.org/wiki/Frank_Bunker_Gilbreth_Sr.
The Hummingbird Effect: How Galileo Invented Timekeeping and Forever Changed Modern Life
by Maria Popova. How the invisible hand of the clock powered the Industrial Revolution and sparked the Information Age.