LKCE16 - Getting to pull at enterprise scale by David J. Anderson

Copyright Lean Kanban Inc. Email: dja@leankanban.com Twi4er: @LKI_dja
True Business Agility
Ge0ng to “pull” at enterprise scale
Presenter
David J. Anderson
Lean Kanban Central
Europe
Hamburg, Germany
November 2016

Kanban is Ubiquitous!

Acceptance
11 years later no one is arguing that Kanban isn’t
appropriate in professional services work
Companies everywhere, large and small, are simply
doing it!
So, it’s Fme to declare victory! We’ve won the
argument that Kanban is a good idea!

China
3 Chinese companies have “very large scale” Kanban
implementaFons
§  Huawei – Telecoms & electronics – 5000+ people
§  Ping An – Insurance & banking – 5000+ people
§  CMB – Banking – 3000+ people
Meanwhile in Europe…
§  Large scale has been seen at Ericsson, Skania, Siemens,
Rolls-Royce, BBVA, Odigeo (eDreams, Opodo) and others

Return on Investment
ImplementaFons at Huawei, Ping An & CMB have
each cost around the equivalent of 3 full Fme
employees salaries
Huawei are seeing improvements in producFvity in
the range of 10-50% with an average of 25% across
more than 10 product units
Improvements at Huawei are the equivalent of 1250
engineers they didn’t need to hire
Return on investment is 300->400:1 or >30,000%

Don’t miss it!
Adam Wu at 17h20
“Ping An China Insurance & Services” Case Study
Kanban across 5000 people
What did it cost?
What has it meant for company performance,
enterprise agility and robustness to disrupFve
ﬁntech?
§  ParFcularly release frequency of mobile ﬁnancial
applicaFons

No Harm!
While there have been failed Kanban
implementaFons, there are no stories of Kanban
doing harm to organizaFons
Unlike some Agile methods and other management
fads such as holacracy, there are no stories of
Kanban causing 20%-40% staﬀ turnover or inﬂicFng
brutal and cruel change
There has been tribal, emoFonal push back in
organizaFons where Agile is a religion

But wait, it’s not Kanban!
The problem with this ubiquitous and virtuous
adopFon of Kanban is that it isn’t really Kanban at
all!

Kanban at MicrosoW 2005
Virtual Kanban “pull” system – No visual boards!
230% producFvity improvement
91% reducFon in average lead Fme
On-Fme performance up from 0% to 98%
Time frame – 15 months
Cost – almost nothing, no coaching fees, no training,
no consultants, 2 permanent team members added
mid-transformaFon taking producFvity from 150%
improvement to 230% improvement

Kanban at Hewle4-Packard 2006
Virtual Kanban “pull” system – no visual boards!
700% producFvity improvement!
Lead Fme on new generaFon of laser printer
ﬁrmware dropped from 21 months to 3.5 months
4.5 day working week
Timeframe – less than 1 year
Cost – almost nothing – no coaches, no training, no
consultants

Proto-Kanban represents minor league victory
What is being implemented at large scale all over the
world is visualizaFon and per person, or per team
WIP limits
Enterprises are struggling to implement end-to-end
“pull” at any signiﬁcant scale!
WHY?

Proto-Kanban

Team Kanban
Backlog
F
H
E
C A
G
D
Next Done
3
In-progress
3∞ ∞
GY
PB
DE
I
J Avatar for each team
memberStill at a single team
level but maturing to
focus on managing
work and less on
managing workers

O
P
R
N
M
L
J
Per Person WIP Limit
Done
F
H E
C
A
I
Pending
G
D
GY
PB DE
MN
AB
Dev/Build/
Test/Deploy
Dev
Ready
GY
GY
PB
PB
MN
MN
DE
DE
AB
AB
K
Bench
Specify
B
∞∞ ∞
Unbounded
Queue
Delayed
WIP
At this level, we are focused
on managing work and
enabling people to self-
organize around it but we
aren’t limiting WIP in the
system as a whole. Hence,
service delivery will not be
predictable
Moving beyond a single
team to a service delivery
workflow

Aggregated Team Kanban
Done
Pool
of
Ideas
F
H E
C A
I
Next
Deploy-
ment
Ready
G
D
GY
PB
DE MN
5 ∞
P1
AB
Ongoing
Development Testing
Done Ongoing Done
3 3
Team 1 Kanban
∞ ∞
Team 2 Kanban

Done
Pool
of
Ideas
F
H E
C A
I
Next
Deploy-
ment
Ready
G
D
GY
PB
DE MN
5 ∞
P1
AB
Ongoing
Development Testing
Done Ongoing Done
3 3∞ ∞
Also
known as
“infinite
done
queues”

Done
Pool
of
Ideas
F
H E
C A
I
Next
Deploy-
ment
Ready
G
D
GY
PB
DE MN
5 ∞
P1
AB
Ongoing
Development Testing
Done Ongoing Done
3 3
Infinite limits on Done columns means that there really isn’t a
kanban pull system present.
This style of proto-kanban controls multi-tasking but doesn’t limit
workflow WIP
∞ ∞

Beneﬁts of proto-Kanban implementa`ons
Benefits
Transparency
Relief from overburdening
Reduced multitasking
Improved quality
People engaged emotionally
More collaboration
Greater empathy

Beneﬁts of proto-Kanban implementa`ons
Benefits
10-50% greater productivity
Up to 50% reduction
in lead times
Average 25% headcount saving
Return on investment
300->400 : 1

Are we there yet?

Kanban Litmus Test
1.  Have managers changed their behavior?
2.  Has the customer interface changed?
3.  Has the customer contract changed?
4.  Has the service delivery business model changed?
If you can’t answer yes to at least 2 of these quesFons
it is unlikely you’ve switched to Kanban yet! You may
have the intent to adopt it through a series of
evoluFonary steps iniFally adopFng proto-Kanban

Have Managers Changed their Behavior?
Are managers managing people, assigning work,
focused on uFlizaFon levels, building brinle,
determinisFc plans, making early customer
commitments and ooen making promises without
regard to capability or respect for risk & uncertainty?
Or have they switched to managing work, focusing
on ﬂow, forecasFng probabilisFcally, deferring
commitment, making promises based on probability,
embracing risk and uncertainty, and focusing on due
date performance against SLAs?

Has the Customer Interface Changed?
Are you sFll anending the same old planning
meeFngs on the same old schedule?
Or, have you adopted kanban system replenishment
meeFngs?
Are customers present at replenishment meeFngs?
Does commitment happen at the replenishment
meeFng when an item is “pulled” onto the board?
Has the frequency of the meeFng changed? Is it
much more frequent than before?

Has the Customer Contract Changed?
Are you sFll making commitments the same way?
Has the promise you make and the way you make it
changed?
Are you sFll making determinisFc plans, promising
precise scope and schedule, and hedging with
conFngency by “overesFmaFng” size, complexity, or
duraFon of work?
Or are you working probabilisFcally, studying historical
data, aggregaFng risk and using service level agreements
as a new style of contract with the customer?

Has the Service Delivery Business Model Changed?
Are you carrying all the risk? Fixed delivery date, fixed
scope, fixed cost? Precise promises based on
determinisFc planning?
Is all work treated homogenously from a risk
perspecFve? Do you process all requests the same way?
Or, have you introduced classes of service based on risk
profiling and assessment of cost of delay? Do you offer
mulFple classes of service by allocaFng capacity and
hedging risk? Is class of service Fed to risk and urgency?
Do you have explicit policy assigning class of service to
different risk profiles?

Triage
“pull” creates a pressure to triage:
§  What should we do immediately?
§  What can wait unFl later?
•  And if so, when? (a scheduling problem)
§  What shouldn’t we do at all? (discard)
If you haven’t developed a strong triage discipline
then you almost certainly haven’t achieved end-to-
end “pull”

Pull

H
F
F
O
M
N
K
J
I
Using movable tokens as kanban is more ﬂexible
Ideas
D
E
A
I
Dev
Ready
G
Development Testing
Test
Ready
F B
C
UAT
Release
Ready
In-progress
Legend
Done
Blocked - issue
Blocked - defect
Override on kanban limit
introduces additional
“blocked – issue” kanban
People working on
blocked item “A”
have been redirected
to work on item “I”

H
F
F
O
M
N
K
J
I
Using movable tokens as kanban is more ﬂexible
Ideas
D
E
A
I
Dev
Ready
G
Development Testing
Test
Ready
F B
C
UAT
Release
Ready
In-progress
Legend
Done
Blocked - issue
Blocked - defect
Using physical slots in the previous example
has been shown to create inertia to
modification & improvement
Using movable tokens allows for
WIP limits to be easily modified and
provides a natural signal token
mechanism

Single Service, Mul`ple Classes of Service
Allocate capacity with kanban limit per color
5 4 4 5 2 = 20 total
AllocaFon
10 = 50%
...
+1 = +5%
4 = 20%
6 = 30%
Input
Buﬀer In Prog Done Done In Prog
Development Analysis Build
Ready Test
Release
Ready

3 Services Aggregated Together
5 4 4 5 2 = 20 total
Change Req
12
Maintenance
2
ProducFon Defect
6
AllocaFon
Total = 20
Input
Buﬀer In Prog Done
Build
Ready Test
Release
Ready Done In Prog
Development Analysis
Released

Change
Requests 3
1
Prod.
Defects
Maintenance
Usability
Improvement
2
1
Improving Liquidity through Labor Pool Flexibility
Teams
F
H
E
C
A
Engin-
eering
Ready
G
D
GY
PB
DE
MN
2
P1
AB
Ongoing
Analysis Testing
Done Verification Acceptance
3 3
Ongoing
Development
Done3
Joe
Peter
Steven
Joann
David
Rhonda
Brian
Ashok
Team
Lead
Junior who will be rotated through
all 4 teams
Generalist or T-shaped
people who can move
flexibly across rows on the
board to keep work flowing
It’s typical to see splits of
fixed team workers versus
flexible system workers of
between 40-60%
Roughly half the labor pool
are flexible workers
Promotions from junior team
member to flexible worker with
an avatar clearly visualize why
a pay rise is justified. Flexible
workers help manage liquidity
risk better!

Irrefutable Demand

Don’t miss it!
Andy Carmichael at 15h20
“IRREFUTABLE DEMAND: When you can’t say “NO””
§  UNDERSTAND YOUR OPTIONS - YOU MAY HAVE MORE
THAN YOU THINK!”

Pressure for “push” is paràlly internal
Why does it feel like “push” is inevitable and unavoidable?
Because so much demand is actually internally spawned from
exisFng commitments!
So many Kanban implementaFons are proto-Kanban semi-
push systems because they service internally generated
demand which is irrefutable
If you are to get to “pull”, you generally have to start with
externally facing customer services
Or insert a strong “definiFon of ready” at the customer facing
point, which states that we will only commit to externally
demand when internal dependency capacity is confirmed (this
has a tendency to lead to undesirable behaviors – big team/
org unit sizes, big batch sizes)

What causes irrefutable demand?
“we’ve already commined to it”
§  PotenFally bad behavior on the part of execuFves or sales
people
§  “the boss wants it”
It’s a legal or regulatory requirement
It’s table stakes for this customer or market niche
It’s mission criFcal
§  High severity producFon defects

Gehng to “pull”
Pull requires that demand is refutable or at least
delayable
Demand must be balanced against capability to
supply
Demand can be shaped
Kanban systems have a noFon of capacity and hence
a strong deﬁniFon of ready may include whether
capacity has been booked in advance using a
dynamic reservaFon system

Is all irrefutable demand as irrefutable as it seems?
Can we use policy to shape demand?
§  For example, sacrifice fidelity or quality on items of a given risk
category or risk profile to bifurcate demand to a shared sevice?
Can we smooth demand through bener understanding of
when to schedule it or its cost of delay?
§  Schedule highest cost of delay items at opFmal start Fme, and
offset others to less opFmal start Fmes while recognizing their
comparaFve cost of delay is lower?
§  i.e. anFcipate overburdening and trade off lost opportunity for
smoother flow, rather than…
§  reacFng to overburdening by delaying items, lengthening lead
Fmes, increasing the tail on the distribuFon and negaFvely
affecFng predictability

You have more management opòns than you
think!
Ensure…
§  Use the feedback loops of risk review, operaFons review &
strategy review to adjust demand to capability
§  Use a holisFc approach to managing the network of
interdependent services
•  OperaFons review
•  Dynamic reservaFon systems
§  Decision making is informed & effecFve
•  Risk profiling
•  Demand shaping thresholds and other policies are explicit
§  Management of uncommined opFons is returned to the
customer

Strategies for irrefutable demand
Deferred commitment negoFated and agreed with customer
Classes of Service
§  maximize flow of value
§  build flexibility to handle variaFon
OperaFons Review cadence to balance demand
Staff liquidity
§  allocate high skilled, mulF-skilled staff before less flexible staff
Examine the constraint/bonleneck in mulFple workflows
§  Use policies to subordinate other parts of the system to the bonleneck
(shape/bifurcate demand)
§  elevate the constraint/bonleneck
Limit capacity / uFlisaFon (e.g. to 50% for planned work)
Reduce work in progress
Manage flow!

Shaping Demand : Triage

Demand Shaping Threshold
Dimension 1
Dimension 2
Dimension 3
Dimension 5
Dimension 4
Definitely
Do
This
Demand shaping
threshold
Talk about
this one
Definitely
Don’t
This
Each risk dimension
represents a taxonomy of
categories describing a
known risk.
Policy describes the
category in each
dimension at or above
which we wish to
accept demand

Demand Shaping Threshold
Dimension 1
Dimension 2
Dimension 3
Dimension 5
Dimension 4
Don’t
Do
This
Exclusion
Zone
Talk about
this one
Definitely
Do
This
Thresholds can be used to as
upper or lower bounds Exclusion zone can be
to the outside or inside
of the graph

Get a Demo of SwiW ESP!

SwiWKanban ESP implements Risk Proﬁling &
Demand Shaping to Manage Large “Backlogs”

Don’t miss it!
Maria Torrijos Lopez at 12h30
“DEALING WITH A MASSIVE BACKLOG AT THE
WORLD'S NO.2 ONLINE TRAVEL COMPANY”
§  Large scale Enterprise Services Planning implementaFon
§  Risk proﬁling in acFon

Organiza`onal Maturity

Personal Kanban
Aggregated
Personal Kanban
Team Kanban
Emergent/Undefined
Workflow
Per Person WIP Limit
CONWIP
Physical space
kanban
Physical token kanban
Virtual Kanban
Classes of service
Capacity allocation
Liquidity optimization
Aggregated teams
Pa4erns of Kanban Board Designs

Risk Hedging

Risk Management
Beneﬁts of improving maturity

What’s Preven`ng Gehng to “pull”?

6 Forces Preven`ng Gehng to “Pull”
1.  Not starFng with a customer facing service
2.  “We are just order takers”
3.  Lack of understanding of business risks
4.  Lack of mathemaFcal literacy
5.  Lack of skills in negoFaFon or forming business
agreements
6.  Lack of conﬁdence planning & scheduling at scale

1. Not Star`ng with a Customer Facing Service
Team Kanban isn’t enough unless the team offers a
bespoke service that is directly customer facing
IniFaFves start where there is enthusiasm and don’t
follow the coaching guidance on “where to start in
large corporaFons”
Internal services suffer from irrefutable demand but
lack the guidance or poliFcal influence to cope with
irrefutable demand

Aﬀec`ng a Paradigm ShiW to “pull”
Kanban coaching guidance on “where to start”
within large organizaFons…
1.  Must be Customer Facing
2.  Must Not be Mission CriFcal
3.  Must be Highly visible
4.  Staﬀ are enthusiasFc
§  indeed may volunteer to pilot the changes

2. We are Just Order Takers
OrganizaFonal structure or corporate governance
that puts product & service delivery funcFons in a
silos without inﬂuence or stewardship over what is
selected, when it is scheduled, and how it is
sequenced, is destrucFve and economically
damaging
Build trust with transparency, visibility, excellence in
delivery, metrics
Encourage greater collaboraFon – replenishment
meeFngs with both sides present - requesters and
delivery

3. Lack of Understanding of Business Risks
Without a framework for analyzing risks and scruFnizing
the analysis, we rely on “the hero product manager”. It’s
low maturity upstream!
A shared language for discussing business, technical and
delivery risks, fosters collaboraFon and consensus
Elevate the product owner from “the single ringable
neck” to the owner of the risk assessment framework
Enterprise Services Planning features a rich risk
assessment framework which is now implemented in
SwioKanban ESP ediFon – get a demo!

Blizzard Sport & Why Risk Assessment Ma4ers
Blizzard
Factory

Blizzard Sport - Reducing Risk Actual Situa`on
ProducFon
Volume
100%
Make-to-forecast
World
Sales Volume
ReporFng to HQ
I II III IV V VI VII VIII IX X XI
0%
Risk
Launch
Volume
100% of total –> 90% risk = 90% risk
Cycle Time

Blizzard Sport – Kanban etc speeds up produc`on
ProducFon
Volume
100%
Make-to-forecast
World
Sales Volume
ReporFng to HQ
0%
Risk
Adapt producFon to make-to-
order
Launch
Volume

Blizzard Sport – Risk assessment & sequencing
produce a larger payoﬀ in risk reduc`on
ProducFon Volume
100%
Make-to-forecast
USA / CAN / JP
Make-to-order
World
Sales Volume
0%
Risk

4. A Lack of Mathema`cal Literacy
The mathemaFcs of probability in lead Fme distribuFons
and forecasFng service delivery is not diﬃcult, but it isn’t
taught in schools or universiFes except to staFsFcians!
Knowing when and where Gaussian distribuFons, Central
Limit Theorem & funcFons of averages such as Linle’s
Law apply and when they don’t is vitally important
You can’t have raFonal conversaFon about when to start
things, or commitments on when or how much will be
delivered without basically mathemaFcal literacy on
probability distribuFon funcFons

5. Lack of Skill in Nego`a`on
Geeks on the delivery side generally haven’t been to business
school.
Business owners & product managers on the requesFng side
have been to business school and received formal training in
the art of negoFaFon
Geeks tend to lose out in negoFaFons
Business people refuse to play the transparent, collaboraFve
game and emoFonally resist real data & evidence
How to deal with this challenge is a skill we teach in Kanban
Coaching Professional classes
§  Create “skin in the game” with collaboraFve workshops – STATIK
§  Or, design kanban systems with layers of classes of service and
capacity allocaFon that can be revealed in response to customer
objecFons

6. Lack of Conﬁdence Planning & Scheduling
Kanban has lacked a comprehensive dependency
management and scheduling system
This is now available in Enterprise Services Planning
Case studies with scheduling & planning boards
appeared as early as 2009 (Posit Science), others
include…
§  Sami Honkonen “Scheduling Work in Kanban” 2011
§  Visotech, Klaus Leopold & Lean Kanban University Press
2014
§  Odigeo, Maria Torrijos Lopez, LKCE Hamburg 2016

Reminder - Don’t miss it!
Maria Torrijos Lopez at 12h30
“DEALING WITH A MASSIVE BACKLOG AT THE
WORLD'S NO.2 ONLINE TRAVEL COMPANY”
§  Large scale Enterprise Services Planning implementaFon
§  Risk proﬁling in acFon
§  Dynamic reserva`on system for scheduling demand

Declare Victory & Fight On!
11 years later no one is arguing that Kanban isn’t
appropriate in professional services work
Companies everywhere, large and small, are simply
doing it!
Kanban is broadly accepted a good thing!
 Now it is `me to actually start doing Kanban properly!

Thank you!

About
David Anderson is an innovator in
management of 21st Century
businesses that employ creative
people who “think for a living” . He
leads a training, consulting,
publishing and event planning
business dedicated to developing,
promoting and implementing new
management thinking & methods…
He has 30+ years experience in the high technology industry starting
with computer games in the early 1980’s. He has led software
organizations delivering superior productivity and quality using
innovative methods at large companies such as Sprint and Motorola.
David defined Enterprise Services Planning and originated the
Kanban Method an adaptive approach to improved service delivery.
His latest book, published in June 2012, is, Lessons in Agile
Management – On the Road to Kanban.
David is Chairman of Lean Kanban Inc., a business operating globally,
dedicated to providing quality training & events to bring Kanban and
Enterprise Services Planning to businesses who employ those who
must “think for a living.”

Screenshots of SwiftKanban ESP risk assessment framework courtesy of Digite
Blizzard Sport inventory at risk assessment slides courtesy of Erix-Jan Kaak and Tecnica
Group
Acknowledgements

Appendices

Dynamic
Reserva`on Systems & Classes of Service
for Dependency Management

Reserva`on systems
First reported by Sami Honkonen, “Scheduling Work in a Kanban” November 2011
hnp://www.samihonkonen.com/wp-content/uploads/2011/11/scheduling-work-in-kanban.pdf

Dynamic Reserva`on & Classes of Service
Based on variability of service delivery throughput
1.  Guaranteed – up to the minimum delivery rate
2.  Reserved (not guaranteed) – minimum to mean delivery
rate
3.  Stand-by – mean to maximum delivery rate
ReservaFon Classes & Kanban
1.  Guaranteed = 6/week
2.  Reserved = 4/week
3.  Standby = 6/week

Dependency discovery
Dependency discovery is a request for informaFon
Dependency discovery should happen upstream and be required
for a “definiFon of ready”
Providing informaFon is a service
We should track dependency discovery requests as work item
types, if the level of effort required is more than a few minutes and
becomes intrusive for one or more people on the service delivery
side
Dependency discovery requests (like many requests for
informaFon, e.g. esFmates) can be disrupFve (and speculaFve)
demand
We should treat dependency discovery like esFmates: don’t do it
unless you really need to; if you need to then control the disrupFve
effect through Fme slicing or resource/service delivery isolaFon

Classes of Service for Reservaòn Systems
We typically associate classes of service with service delivery
and the queuing discipline of Fckets flowing through Kanban
boards
We can use classes of service for reservaFons in scheduling
systems. For example, you can hold a “stand by” reservaFon
for a “first class” air Fcket. Different classes of services for the
reservaFon versus the actual flight

Use risk profiling to determine whether you care about delay
from dependency risk
§  E.g. if we have a low cost of delay why would we bother to explicitly
manage for dependencies which may cause delay
Determine a class of service which directs policy on how (or if)
you will manage dependencies for an item and how a
reservaFon will be made
§  In which Fme slot should we make a reservaFon and which class of
service (guaranteed/reserved/stand-by) is appropriate

Class 1: No Dependency Management
Lead Fme distribuFons already accounts for
dependency delays
§  No anempt to discover dependencies
Low risk of incurring any signiﬁcant cost of delay, or
We have the ability to start early enough that we
don’t care about lead Fme tail risk
So just do it, don’t worry about dependencies. Let
them happen if they will!
No reservaFon for the calling service or called service
ProbabilisFc dependency, probabilisFc scheduling

Class 2: Tail Risk Mi`gaòn. Reserved Capacity
Care about tail risk due to cost of delay in the calling service e.g.
change request for IT system maintenance. Tail risk is increased
when a dependency exists, e.g. DBA (the called service)
No anempt to determine if a specific dependency occurs or
when specific capacity will be required on the [DBA service]
Needs reliable service and predictable queuing on the called
service, e.g. DBAs
Allocate capacity on the [DBA service] for probabilisFcally
anFcipated demand. Use "outcome-driven design“ to design for
anFcipated demand with STATIK. Linle's Law provides average
delivery capability defining a WIP limit for capacity
Demand shaping. Shape demand from the calling service against
average delivery capability. Avoid overburdening the [DBA
service]

Class 2: con`nued…
Track lead Fme on the called service from request
submission, as request is already commined. By deﬁniFon
demand on the [DBA service] is irrefutable. “Push”
demand. Lead Fme distribuFon and SLA will take into
account queuing Fme delay at the front end of the [DBA
service].
If dynamic booking system is implemented
§  Schedule slot(s) on the [DBA service] suﬃciently far ahead to
account for the tail of its lead Fme distribuFon
§  Use "Standby" class of service for the reservaFon
§  Book several similar reservaFons, or have capability to rebook a
missed reservaFon
Reserve a series of “standby” class slots for the calling
service work item. No reservaFon on the called service –
we don’t know whether the dependency exist or not

Class 3: Known Dependency. Informed Scheduling
Cost of delay is more criFcal, or not pracFcal to start early
enough to miFgate tail risk
Add analysis (informaFon request) to determine if
dependencies exist. Filter lead Fme distribuFon for work
items with same dependencies
Use filtered lead Fme to facilitate scheduling & selecFon
DefiniFon of ready requires determinaFon of whether a
dependency exists or not
Use capacity allocaFon, demand shaping on called service
As class 2 but book a “reserved” slot on the calling system. No
reservaFon on the called system because the filtered calling
system lead Fme distribuFon accounts for the effect of the
dependency
DeterminisFc dependency, probabilisFc scheduling

Class 4: Known dependency. Specific Scheduling
Cost of delay is significant or criFcal, or deferred commitment
is valuable as addiFonal informaFon arrival to miFgate other
risks is required to facilitate (in/out) selecFon decisions, or
simply not possible to start early enough to miFgate tail risk
Treat as class 3 and in addiFon…
AnFcipate approximately when dependency will occur.
Forecast Fme from commitment to dependency occurring.
Book a "reserved" class kanban in the dynamic reservaFon
system for the calling service
Book a “guaranteed” slot for the called service
Calling service definiFon of ready requires a booking on the
called service
DeterminisFc dependency, determinisFc scheduling

Class 5: No margin for error
As class 4 but deﬁniFon of ready is Fghtened to
"Guaranteed" class booking in the reservaFon
system for both the work items on the calling service
and the called service
DeterminisFc dependency, determinisFc scheduling

Class 1 Dependency Management
Calling Service
Called Service
We Don’t Care!
No WIP limits
Dependency impact
is built into customer
lead time distribution.
We start early enough
& cost of delay is low
enough that we don’t
need to explicitly
manage the
dependency

Calling Service
Called Service
WIP limits
[5]
[2]
We wish to mitigate the
tail risk in the customer
facing lead time by
insuring dependency
delivery is predictable &
reliable as a
consequence of
reserved capacity on
the called service

Calling Service
Called Service
ReservaFon system
[5]
[2]
Filtered lead Fme
“Reserved” Class
Booking
Dependency
Analysis
Determine the
dependency exists,
make a reservation
for it to insure
capacity on the
called service when
we need it!

Calling Service
Called Service
ReservaFon system
“Reserved”
“Guaranteed” Class
Booking
“Defn of Ready”
requires
conﬁrmed
booking on
called service
We want a high
confidence in the start
time for customer lead
time. We take no risk
on dependent
capacity becoming
available

Calling Service
Called Service
“Guaranteed”
“Guaranteed” Class
Booking
“Defn of Ready”
requires
conﬁrmed
“Guaranteed”
booking on
called service
No margin for error!
We want 100%
confidence in the
start time for
customer lead time
and no risk on
dependent capacity
availability

Mul`ple Reserva`ons
Cost of delay (and other risk assessment) can be
used to establish, opFmal start, and whether earlier
or later is preferred if opFmal isn’t available
Make mulFple bookings at lower classes of service
“reserved”, or “standby” for the same item.
If it shows up early and capacity is available start it,
cancel its other reservaFons
“Guaranteed”
“Reserved”
“Stand by” 3 bookings for same Fcket

Dependency Management & Cost of Delay
Desired delivery date
Super-Linear Region
Class 2
Class 4
Class 2

Dependency Management & Cost of Delay
Desired delivery date
Sub-Linear Region
Class 1
Dependency Management

LKCE16 - Getting to pull at enterprise scale by David J. Anderson

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (11)

Similaire à LKCE16 - Getting to pull at enterprise scale by David J. Anderson

Similaire à LKCE16 - Getting to pull at enterprise scale by David J. Anderson (20)

Plus de Lean Kanban Central Europe

Plus de Lean Kanban Central Europe (20)

Dernier

Dernier (15)

LKCE16 - Getting to pull at enterprise scale by David J. Anderson