[Talk] Manage flow - Metrics and Analytics for predictability and flow

Manage Flow
Metrics and analytics for predictability and flow
Principal Consultant
marcio.sete@elabor8.com.au
Marcio Sete
@marciosete

@marciosete
#1 - The three actionable metrics of
ﬂow are WIP, Lead time and Throughput

@marciosete
Work In Progress (WIP)
The number of items that we are working on at any given time. All discrete
units of customer value that have entered a given process but have not exited.
Lead Time
- How long it takes each of those items to get through our process.
- The amount of elapsed time that a work item spends as Work In Progress.
Cycle time
- The amount of elapsed time that a work item spends in a specific stage of
the workflow
Throughput
The amount of WIP completed per unit of time.

DonePool of
Options
Testing
Ongoing Done
2
Ongoing
Development
Done
3Committed 2 Deployment 1
AB
CD
F G
H
I PB
DE
E
AB
MN
GY
Lead Time
Commitment Point Delivery Point
Entry
Criteria
Pull
Criteria
Pull
Criteria
Pull
Criteria
Exit
Criteria
AA
WIP-limited, pull-based Kanban System
@marciosete
Arrival Point
Lane
Criteria
Cycle Time
Throughput

It’s a matter of scale
@marciosete
Customer Lead Time
Cycle Time
System Lead Time
Cycle Time
System Lead Time
Cycle Time

Who is the customer?
@marciosete
End customer
When you’re serving those who represent your market share
Downstream customer
When you’re part of a value stream and a downstream system will take your output as
their input to serve the end customer
Service delivery customer
When you serve teams with subject matter expertise in order for them to deliver their
work to either a downstream customer or the end customer
Internal executive customer
When your service outcome is a building block to a bigger initiative that another area of
the business is putting together to serve the end customer

@marciosete
Some reasons to not use Velocity and Story Points
● Your customers don’t talk story points, they talk elapsed days, not even working days
● Story points are a matter of effort and complexity and don't consider queues and delays
○ Your customers don’t care about your Velocity or how many story points were
assigned to a User Story; they care about when they will seize their business value
● Velocity and Story points deal with average.
○ You don’t forecast using averages unless you’re ok being wrong 50% of the time
● A story point is a proxy metric
○ It leaves room for interpretation
○ You can’t use it to compare, although it will be used
○ It’s not actionable
● It’s commonly referred to as the Team Velocity, not the System Velocity
○ Which is used for blaming, creating overburdening
● We don’t estimate in a deterministic way something full of uncertainty and variability
○ You never give an estimation without a date range and a probability

@marciosete
#2 - The most important thing you can
do to improve predictability and ﬂow is
to match your arrival rate (commitment)
with your departure rate (throughput)

DonePool of
Options
Testing
Ongoing Done
2
Ongoing
Development
Done
3Committed 2 Deployment 1
AB
CD
F G
H
I PB
DE
E
AB
MN
GY
Lead Time
Commitment Point Delivery Point
Pull
Criteria
Pull
Criteria
Pull
Criteria
Pull
Criteria
Pull
Criteria
AA
WIP-limited, pull-based Kanban Systems have clear boundaries
@marciosete
Arrival Point
Lane
Criteria
Cycle Time
Throughput

CumulativeFlowDiagram
@marciosete

Mismatched Arrivals and Departures
Actionable Agile Metrics for Predictability - Daniel S. Vacanti@marciosete

Mismatched Arrivals and Departures
Actionable Agile Metrics for Predictability - Daniel S. Vacanti
@marciosete

Little’s Law
@marciosete
Average Cycle Time = Average Work In Progress / Average Throughput

Arrival/DepartureRate
@marciosete

@marciosete
#3 - Don't use averages to forecast
when you can work with distributions

@marciosete
How long that will take?
Average 26
Mode 9
30 Percentile 13
50 Percentile 16
70 Percentile 24
85 Percentile 42
95 Percentile 83
Max 154
Min 4

LeadtimeScatterplot
@marciosete

MonteCarloSimulation-WHEN
@marciosete

MonteCarloSimulation-HOWMANY
@marciosete

@marciosete
#4 - Flow debt is when lead time is
artiﬁcially reduced for some work in
progress by “borrowing” lead time from
other pieces of work

@marciosete
#5 - Poor pull-transaction policies and
misused classes of service are the
primary sources of ﬂow debt

Flow Simulation
● Backlog of 50 items.
● All of our items takes
exactly 10 days to go
through each column.

Strict FIFO pull order with no Expedites

Random pull order with no expedites

FIFO pull order with always one expedite
on the board

Random pull order with always one
expedite on the board

Flow Simulation - results side by side

@marciosete
#6 - Use the 85 percentile of your lead
time distribution as the SLA for your
service delivery

@marciosete
#7 - When slicing the work, it's not
about same-sizing; it's about
right-sizing. Check your work items
against the 85 percentile of your lead
time distribution

@marciosete
#8 - The more you violate Little Law's
assumptions, the less chance you have
of being predictable

@marciosete
Little’s Law constraints to ensure
predictability and flow
Average Cycle Time = Average Work In Progress / Average Throughput
1. The average input or Arrival Rate should equal the average output or Departure
Rate (Throughput)
2. All work that is started will eventually be completed and exit the system.
3. The amount of WIP should be roughly the same at the beginning and at the end of
the time interval chosen for the calculation.
4. The average age of the WIP is neither increasing nor decreasing.
5. Cycle Time, WIP, and Throughput must all be measured using consistent units.
* Use these assumptions as a guide for your process policies. The more you violate these assumptions, the less chance you have of being predictable.

@marciosete
#9 - Queue time is your invisible killer

40%
20%
100%
15%
40%
30%
75%
75%
Work item 1
Work item 2
Work item 3
Work item 4
Work item 5
Work item 6
Work item 7
Work item 8

@marciosete
The shocking reality organisations face today

@marciosete
Effectiveness of organisations’ working time

@marciosete
#10 - The formula for evolutionary
changes is: stressor, reﬂection
mechanism and leadership

Traditional Change is an A to B process
A is where you are now. B is a destination.
• B is either defined (from a methodology definition)
• or designed (by tailoring a framework or using a model based approach such as value stream mapping
Current
Process
Future
Process
Defined
Designed
transition
@marciosete

What change really feels like: The J Curve
@marciosete

Evolutionary change has no defined end point
Evolving
Process
Roll
forward
Roll
back
Initial
Process
Future process is
emergent
Evaluate
Fitness
Evaluate
Fitness
Evaluate
Fitness
Evaluate
Fitness
Evaluate
Fitness
We don’t know the end-point
but we do know our emergent
process is fitter!
@marciosete

Fitness
Time
Evolutionary change with many small J’s
@marciosete

@marciosete
The formula for evolutionary changes
● Stressor
● Reflection mechanism
● Leadership
The essence of Kanban

Principal Consultant
https://www.linkedin.com/in/marciosete
https://twitter.com/elabor8
https://twitter.com/marciosete
https://medium.com/@Elabor8
https://medium.com/@marciosete
Thank you! Obrigado!
www.elabor8.com.au
marcio.sete@elabor8.com.au
Marcio Sete

[Talk] Manage flow - Metrics and Analytics for predictability and flow

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à [Talk] Manage flow - Metrics and Analytics for predictability and flow

Similaire à [Talk] Manage flow - Metrics and Analytics for predictability and flow (20)

Plus de Marcio Sete

Plus de Marcio Sete (20)

Dernier

Dernier (20)

[Talk] Manage flow - Metrics and Analytics for predictability and flow