Showing posts with label lead time. Show all posts
Showing posts with label lead time. Show all posts
Whiskey, Sushi and Flow
abstract:
Come participate in a conversation that challenges you to think about everyday implicit flow parameters. Let's chat about my bar, and my frustration while waiting for a temaki on a Japanese restaurant.. These examples will help us understand and talk about flow parameters and queues.
Little’s law and stable systems
Little’s law is defined in terms of stable systems. On my previous post, I have described my bar as a stable system: “Whenever a bottle finishes, I remove it from the bar. Then I open a new one, and add it to the bar. My bar is a stable system: the rate at which whiskey bottles enter the bar is the rate at which they exit.”
This describes the mechanics for inbound and outbound work items (whiskey bottles); but what is guiding these decisions?
Basically two guiding rules make my bar a stable system: (1) WIP limit and (2) Pull System.
WIP limit
WIP, or work in progress, is the number of work items in my system. In my bar example it is the number of whiskey bottles on the bar. Bottles that have been opened, but are not finished yet. The WIP limit on my bar is 12 bottles because that's all I have space for.
Pull System
Pull System describes the movement of work items driven by actual demand. In my bar example, a bottle that is finished opens a spot on my bar. Therefore creating a demand for a new bottle to be opened and placed at the bar. Essentially, the movement of work items (whiskey bottles) is driven by actual demand: a finished bottle is removed from the bar, opening space for a new one that is promptly added to the bar, occupying the vacant space..
Lead time: Applying Little's Law to track it
“The average number of work items in a stable system is equal to their average completion rate, multiplied by their average time in the system.” ~ John Little, 1961
The text above is from "A Proof for the Queuing Formula" by Little,
J. D. C. (1961). It is knows as the Little’s law.
By solving this simple first equation you are able to find out the
average time for work items in your system. My whiskey bar provides us a great stable system example to illustrate how
you can apply Little’s law to track the average lead time.
My whiskey bar
| my bar |
Whenever a bottle finishes, I remove it from the bar. Then I open a new
one, and add it to the bar. My bar is a stable system: the rate at which whiskey bottles enter the bar
is the rate at which they exit.
Let's apply Little's law
Little’s law: “The average number of work items in a stable
system is equal to their average completion rate, multiplied by their average
time in the system.”
Or
The average number of
work items in a stable system
=
average completion
rate
X
average time in the
system
Using my bar terms:
12 bottles (number of whiskey
bottles in my bar)
=
6 bottles / year (average
completion rate)
X
average time in my bar
Therefore,
the average time a whiskey bottle stays in my bar is 2 years.
Give it a
try! Go ahead and apply the Little’s Law formula to your stable system. Similarly to
my bar example, given the average work items in the system (WIP) and the completion
rate (throughput), you can derive the average time in the system (lead-time).
Lead Time - three extremely simple ways to manually track it
Lead time—the time elapsed from the work start to completion-- is important and is a key performance indicator (KPI) that every Agile team should track. Poor lead time causes bottlenecks in the team production flow, inefficiencies, delay costs, not to mention unhappy customers. Below are three extremely simple ways to manually track it on your card wall.
Write on card
The easiest way to track the lead time for a work item is to write on the card itself. I typically write on the back of the card the date the work started, and then, when it is done, I write the date again. By subtracting the dates you get the lead time for that work item.
Banana peal
This is a story about a very creative team. The team was very interested on maintaining really short lead times; three days for a work item completion was outrageous! Vini was a developer on that team. He used to bring bananas daily. Banana was his breakfast.
The team decided to tape a banana peal on every work item that started on that day. This was done on the morning stand up. In a few days the banana peal goes from yellow to black (and rotted). The lead time was very visible on the wall. Work item taking more than two days were very visible to the whole team. It was impossible not to pay very close attention to every work item lead time.
Interesting enough, the cleaning people were the first ones to complain about long lead times on that project.
Red dots
Every day that goes by, a new red dot goes on the card. Below is a sequence of photos for a work item card. The photos were taken day 1, day 2, day 3, and then day 10. You simply count the dots to find out how long the work item is taking. For each completed work item, the number of dots depicts the lead time.
Write on card
The easiest way to track the lead time for a work item is to write on the card itself. I typically write on the back of the card the date the work started, and then, when it is done, I write the date again. By subtracting the dates you get the lead time for that work item.
![]() |
| work started |
![]() |
| work compteled |
Banana peal
This is a story about a very creative team. The team was very interested on maintaining really short lead times; three days for a work item completion was outrageous! Vini was a developer on that team. He used to bring bananas daily. Banana was his breakfast.
The team decided to tape a banana peal on every work item that started on that day. This was done on the morning stand up. In a few days the banana peal goes from yellow to black (and rotted). The lead time was very visible on the wall. Work item taking more than two days were very visible to the whole team. It was impossible not to pay very close attention to every work item lead time.
![]() |
| visual lead time via a banana peal |
Red dots
Every day that goes by, a new red dot goes on the card. Below is a sequence of photos for a work item card. The photos were taken day 1, day 2, day 3, and then day 10. You simply count the dots to find out how long the work item is taking. For each completed work item, the number of dots depicts the lead time.
![]() |
| day 1 |
![]() |
| day 2 |
![]() |
| day 3 |
![]() |
| day 10 |
Continuous Delivery: lead time and cycle time
I have seen
quite a few people mixing up these terms: lead time and cycle time.
I am not
sure about the reason for the confusion. I think Continuous Delivery
provides a great example for explaining each one of these important parameters:
lead time and cycle time.
Manufacturing
Lead time and cycle time are concepts from manufacturing, therefore I use the drawing below for explaining it. On it, a sample manufacturing assembly line, depicting a visual representation for lead time (L) and cycle time (C).
Lead time and cycle time are concepts from manufacturing, therefore I use the drawing below for explaining it. On it, a sample manufacturing assembly line, depicting a visual representation for lead time (L) and cycle time (C).
- Lead time: the amount of time a work item takes from the beginning to the end of the workflow
- Cycle time: the interval of time between two consecutive work items leaving the workflow.
The
assembly line provides a visual and physical representation for the workflow.
In manufacturing, the workflows as well as the work items are visible. This is
not the case on Software delivery. Neither workflow nor work items are naturally
visible.
Continuous Delivery
Continuous Delivery is a software development discipline that fosters faster and more frequently releases. The deliverable is incrementally built on the delivery workflow (represented on the drawing below), starting on coding, and ending on production. Continuous Delivery relies on high levels of build, integration, test, and deployment automation.Continuous Delivery
Below is a representative drawing for Continuous Delivery.
Now I will
mix the drawings (Continuous Delivery and assembly line) a little bit.
This drawing
creates a visual representation for work items moving on a Continuous Delivery
workflow. The box coming out of the assembly line represents a deliverable reaching production. The red X mark with the red arrow represents a work item taken out of the assembly line (failed some test).
- Lead time: The amount of time a work item takes since it is first committed until it reaches production.
- Cycle time: the interval of time between two consecutive deliverable to production.
Continuous Delivery fosters faster and more frequently releases, or using the manufacturing terms: Continuous Delivery fosters shorter release lead time and cycle time.
7 ways to track lead time
Abstract:
Measuring lead time is important and is a key performance indicator
(KPI) that every Agile team should track. Poor lead time causes bottlenecks in
the team production flow, inefficiencies, delay costs, not to mention unhappy
customers. Come to this session to discuss with others how to track and monitor
improvement on lead time.
Subscribe to:
Posts (Atom)






