Delivery better predictability, business agility and governance with Kanban. These three goals are often important to senior executives in technology companies. It is often assumed that these goals are mutually exclusive and you have to focus on one, maybe two but all three cannot be achieved together. This talk presents Kanban for an executive audience and explains how it enables all 3 goals - better predictability, business agility without sacrificing governance.
3. Microsoft 2004 - the XIT Story
Change requests
PTCs
Product
Managers
PM
Testers
RequestsDevelopers
for estimates or analysis of
future work are often
‚invisible‛, have an unpredictable
arrival rate & are given priority. &
Emergency work is unplanned User Acceptance
receives highest priority. Arrival rate
& volume are unpredictable.
PTCs? What did that acronym mean?
Items that did not require coding!
Effect is hugely disruptive!
Why were they treated as
emergencies?
Prioritized
Backlog
dja@djaa.com, @agilemanager
Waiting for
Test
4. Predictability, Agility & Governance
So how were they doing on our
PTCs
measures of predictability, agility &
governance?
Product
Testers
Developers
Managers
On-time delivery was 0%. There was a 100%
chance of interruption to estimate future
work.
User Acceptance
Planning & prioritization were conducted
monthly. Fastest response from receipt to
deployment was around 6 weeks.
But everything had a business case and was
prioritized by ROI!
So the drive for good governance was
Prioritized
destroying predictability and agility!
Waiting for
Backlog
Test
dja@djaa.com, @agilemanager
5. What Were the Issues?
So what issues affected the outcome?
PTCs were governance policies so
Why
disruptive?
Testers
Developers
Product
Managers
Product managers demanded fast response on
estimates to facilitate future planning and
provide fast feedback to business owners. User Acceptance
Entire backlog was planned & commitments
made early. 90% of the backlog was re-planned
each month.
Expedite policy for PTCs was folklore – no one
could explain why
Process Improvement Conclusion
Controlling unplanned, disruptive
Prioritized
demand would improve
Waiting for
Backlog
predictability!
Test
dja@djaa.com, @agilemanager
6. A virtual kanban system was chosen
Backlog
Engineering
Ready
5
Change
Requests
Pull
F F
F
F F
F
F
PTCs
G
Development
Test
Ready
Testing
UAT
3
5
3
∞
Ongoing
Done
It’s important to realize the process
for software development did not
B
Pull change. The kanban system is an
overlay on the existing process. It
G
C
Pull
changes scheduling and prioritization
only
F
D
PTCs are permitted to break the
kanban limit
*Blocked to service PTC
dja@djaa.com, @agilemanager
*
I
Deployment
Ready
∞
7. CRs
50
240%
improvement
in delivery
rate
The Results Backlog depleted.
Serving at rate of
demand
30
Average
Time to Resolve
10
Time (in quarters)
125
90% drop in end-toend cycle time*
75
25
* Includes queuing time prior to selection
dja@djaa.com, @agilemanager
Time (in quarters)
10. Commitment is deferred
Backlog
Engineering
Ready
5
Testing
UAT
3
5
3
∞
Ongoing
Done
Items in the backlog remain
optional and unprioritized
Change
Requests
Pull
F F
F
F F
F
F
Development
Test
Ready
D
G
E
Wish to avoid discard after commitment
PTCs
Commitment point
dja@djaa.com, @agilemanager
We are committing to getting
started. We are certain we want
to take delivery.
I
Deployment
Ready
∞
11. Discard rates are often high
Backlog
Engineering
Ready
5
Development
Test
Ready
Testing
UAT
3
5
3
∞
Ongoing
Done
The discard rate with XIT was 48%.
~50% is commonly observed.
Change
Requests
F F
F
F
G
Reject
Deferring commitment and
Options have value because the
avoiding interrupting
future is
Dworkersuncertain
for estimates
E
0%makes rate implies there is
discard sense when discard
no uncertainty about the future
rates are high!
PTCs
I
Discarded
I
dja@djaa.com, @agilemanager
Deployment
Ready
∞
12. Specific delivery commitment may be
deferred even later
DeployEnginBacklog
eering
Ready
5
Development
Test
Ready
Testing
UAT
3
5
3
∞
Ongoing
Done
ment
Ready
∞
Change
Requests
Pull
F F
F
F F
F
F
D
G
E
PTCs
We are now committing to a
specific deployment and
delivery date
Discarded
*This may happen earlier if
I
circumstances demand it
I
dja@djaa.com, @agilemanager
2nd
Commitment
point*
13. Replenishment Cadence
Backlog
Engineering
Ready
5
Replenishment
Change
Requests
Pull
F F
F
F F
F
F
Development
Test
Ready
Testing
UAT
3
5
3
∞
Ongoing
Done
Frequent replenishment is
more agile.
On-demand replenishment is
D
most agile!
G
PTCs
Discarded
I
dja@djaa.com, @agilemanager
E
The frequency of system
replenishment should reflect
arrival rate of new
information and the
transaction & coordination
I
costs of holding a meeting
Deployment
Ready
∞
14. Delivery Cadence
Backlog
Engineering
Ready
Pull
F F
F
F F
F
F
Testing
UAT
3
5
3
∞
Ongoing
Done
Frequent deployment is
more agile.
5
Change
Requests
Development
Test
Ready
Deployment buffer size can
On-demand deployment
reduce as frequency of
D deliveryagile!
most increases
G
PTCs
Discarded
I
dja@djaa.com, @agilemanager
is
E
The frequency of delivery
should reflect the transaction
& coordination costs of
deployment plus costs &
toleranceI of customer to take
delivery
Deployment
Ready
∞
Delivery
15. Defining Lead Time
Backlog
Engineering
Ready
5
The clock starts ticking when
Test
UAT
we Ready
customers
Development accept theTesting
5
∞
3 order, not when it3is placed!
Ongoing
Done
Until then customer orders are
merely available options
Lead time (through
Change
Requests
the kanban system)
ends when the item
reaches the first
Pull
F F
F
F F
F
F
Deployment
Ready
∞
D
∞ queue.
I
G
E
This provides the
correct result for
Little’s Law and
visualization on a
Cumulative Flow
Diagram
Lead Time
PTCs
Discarded
I
dja@djaa.com, @agilemanager
18. Factors Affecting Agility
Kanban decouples replenishment
from lead time & delivery enabling
The businesstailoring of the process to the
agility of the system is determined
by the replenishment of the business domain
dynamics cadence, the delivery
cadence and the lead time (or end-to-end cycle
time) through the system.
dja@djaa.com, @agilemanager
19. Benefits of Limiting WIP
Backlog
Engineering
Ready
5
Change
Requests
Pull
F F
F
F F
F
F
G
Development
Test
Ready
Testing
UAT
3
5
3
∞
Ongoing
Done
Limiting WIP reduces multi-tasking.
Shortens lead time. Focuses
E
organization on impediment removal
D
#*
Bug
and limits due date performance
degradation from poor quality &
rework
Lead
Blocked!
Time
PTCs
*Specialist
test environment
unavailable
Blocked!
Discarded
I
I
Defect found requiring coding
fix
dja@djaa.com, @agilemanager
Deployment
Ready
∞
20. Observe Lead Time Distribution as an enabler
of a Probabilistic Approach to Management
Lead Time Distribution
3.5
3
CRs & Bugs
2.5
2
1.5
1
0.5
1
4
7
0
3
6
8
14
14
13
12
12
11
10
99
92
85
78
71
64
57
50
43
36
29
22
8
15
1
0
Days
This is multi-modal data!
The workexpectation of
SLA is of two types:
Change Requests (new
105 and Production
features);days with 98 %
Defects
Mean of 31
days
SLA expectation of
44 days with 85% on-time
dja@djaa.com, @agilemanager
on-time
21. Mean
5 days
Change Requests
Production Defects
Filter Lead Time data by Type of Work (and
Class of Service) to get Single Modal
Distributions
98% at
25 days
85% at
10 days
dja@djaa.com, @agilemanager
98% at
150 days
Mean
50 days
85% at
60 days
22. Allocate Capacity to Types of Work
Backlog
Engineering
Ready
Ongoing
2
Change
Requests
Development
5
3
Done
Testing
3
Verification Acceptance
Consistent capacity allocation
E
some consistency to
should bring more consistency to
MN
delivery rate of work of each
D
AB
type
F
Lead Time
PB
DE
Productio
n
Defects
I
Deployment
Ready
3
G
P1
GY
Separate understanding of
Separate understanding of Lead
Lead Time for each type of
Time for each type of work
work
Lead Time
dja@djaa.com, @agilemanager
∞
Done
23. Flow Efficiency
Flow efficiency measures the
percentage of total lead time
Pool is Engin- actually adding
that spent
of
eering
value (or knowledge) versus
Development
Ideas
Ready
waiting
3
Ongoing
2
Done
Testing
3
Verification Acceptance
Deployment
Ready
∞
Until then customer orders
are merely available options efficiency = Work Time
Flow
Lead Time
Flow efficiencies of 2% have been
F
reported*. 5% -> 15% D normal, P1
is
>
40% is good!
G
E
PB
I
GY
DE
Waiting Working
MN
AB
Waiting
Working Waiting
Lead Time
* Zsolt Fabok, Lean Agile Scotland, Sep 2012, Lean Kanban France, Oct 2012
dja@djaa.com, @agilemanager
Done
x 100%
24. Benefits of Reducing Lead Time
Backlog
Engineering
Ready
5
Change
Requests
Pull
F F
F
F F
F
F
PTCs
Discarded
Development
Test
Ready
Testing
UAT
3
5
3
∞
Ongoing
Done
Short lead times enable later
commitment, reduce likelihood of
post-commitmentE
discard or rework
D
Bug
due to perishable nature of
Bug
information and improve quality as
G
Bug
defect insertion rates fall nonlinearly reduces chance of
Short lead timewith reduced lead time
discard
Defect insertion rate increases
non-linearly with long lead
times and low flow efficiency.
I
Defect fix times increase nonlinearly with delay time from
I
discovery to fix
dja@djaa.com, @agilemanager
Deployment
Ready
∞
25. Flow
Efficiency (%)
More Results (from 2005)
Flow efficiency
improved from
8% to 92%
75
45
Due Date
Performance
15
These improvements were minimally
intrusive, met with little to no resistance
(though some managerial derision) and
cost almost nothing!
75
If Time (in quarters) well,
it works this
perhaps we should try this
DPP improved
again?!!
almost instantly
45
15
* Measured from point of commitment
dja@djaa.com, @agilemanager
from 0% to 98%
against lead time
SLA*
Time (in quarters)
26. Ability to handle variety and heterogeneity
of risks improves business performance
Kanban enables us to build a trusted
The kanban system explicitly exposes the
delivery capability. Agility and
business risks in terms of types of demand,
predictability are tuned to the
quantity & rate of demand. It helps us to
understandinherent risks in the business
the costs & benefits of frequent
interaction with upstream & downstream
domain!
functions. And it gives us a temporary and
quantitative understanding of our capability to
deliver against demand
dja@djaa.com, @agilemanager
28. Key Risk to Manage is “What to Pull Next?”
Pool
of
Ideas
Engineering
Ready
4
∞
Development
Ongoing
3
Done
Deployment
Ready
Testing
3
Verification Acceptance
∞
Replenishing the system is an act of commitment
– selecting items for delivery. Committing to the
cost to convert from options into real value.
J
K
L
G
Pull Selection is choosing from immediate
options – an act of dynamic prioritization of the
I have 4 options, which one
Pull
D most immediate risk attached to it
E
item with the
should I choose?
I
System
Replenishment
F
Pull
Pull
Selection
dja@djaa.com, @agilemanager
Done
29. Change Requests
The psychology of a probabilistic approach
can be challenging…
I don’t want to take the risk of
being longer than 60 days. Mean
I need
a precise estimate of when it
50 days
will be delivered!
98% at
150 days
85% at
60 days
dja@djaa.com, @agilemanager
30. impact
impact
Cost of Delay is a critical business risk
impact
impact
time
Expedite – critical and immediate cost of
delay; can exceed other kanban limit
Qualitative approaches to risk
(bumps other work)
management using taxonomies of 2 to 6
time
categories for each dimension of risk goes up
Fixed date – cost of delay have
been shown to fast, cheap & effective in
significantly after deadline; Start early
comparison to quantitative methods that to insure
enough & dynamically prioritize
often involve speculation and false
on-time delivery
time
precision
Standard - cost of delay is shallow but
accelerates before leveling out; provide a
reasonable lead-time expectation
impact
impact
time
time
Intangible – cost of delay may be
significant but is not incurred until much
later; important but not urgent
impact
time
time
dja@djaa.com, @agilemanager
31. Implementing Classes of Service
Engineering
Ready
Development
Ongoing
Expedite
Fixed
Date
Standard
3
Done
2
E
D
3
F
1
I
dja@djaa.com, @agilemanager
3
Verification Acceptance
Different distributions for
2
different classes of service
increases the level of trust that
1
an item will be delivered in a
timely manner, demonstrating
P1
that cost of delay is a risk under
management
G
Intangible
Testing
Deployment
Ready
∞
Done
32. impact
The Optimal Exercise Point
If we start too early, we forgo
the option and opportunity to do
something else that may provide
value.
If we start too late we risk
Ideal Start
incurring the cost of delay
When we
need it
Here
With a 6 in 7 chance of on-time
delivery, we can always expedite
to insure on-time delivery
85th
percentile
Commitment point
dja@djaa.com, @agilemanager
33. Hedge Delivery Risk by spreading capacity
across items of differing urgency
Engineering
Ready
2
Expedite
Ongoing
2
3
Done
Testing
3
Verification Acceptance
∞
1
Fixed
Date
Development
Deployment
Ready
Standard
Uncertainty in demand or
E
arrival rate of urgent &
critical items is offset with
capacity for items that are
easily delayed
F
D
3
G
Intangible
3
I
dja@djaa.com, @agilemanager
Done
34. Cost of Delay attaches to a deliverable
So understanding cost of delay
Yes, however, it isn’t always relevant! Cost of
enables us to know what to pull
delay attaches to a deliverable item. What if
next?
that item is large? Whole projects, minimum
marketable features (MMFs) or minimum viable
products (MVPs) consist of many smaller items.
We need to understand the risks in those
smaller items too, if we are to know how to
schedule work, replenish our system and make
pull decisions wisely
dja@djaa.com, @agilemanager
35. Make a long term plan to build
platform replacement
Device Management Ike II Cumulative Flow
2008
30
-M
ar
23
-M
ar
5x
9M
ar
2M
ar
eb
24
-F
eb
2006
17
-F
10
-F
Slope in middle
3.5x - 5x slope
at ends
16
-M
ar
240
220
200
180
160
140
120
100
80
60
40
20
0
eb
Features
Required throughput (velocity)
During the middle 60% of the project schedule we
Time
need Throughput (velocity) to average 220 features
Inventory Started Designed Coded Complete
per month
dja@djaa.com, @agilemanager
36. Little’s Law
Determines
staffing level
Calculated based on
known lead time
capability & required
PlandeliveryChanging the WIP limit without
based onrate
currently observed
maintaining the staffing level
capability and current working
ratio assume process
practices. Do not represents a change to the
way of working. It is a change to
improvements.
the process and will produce a
Delivery Rateto reduce undesirable‘common
change in the observed
If changing WIP
cause’ capability new
effects (e.g. multitasking), get of the system
Lead Time
sample data (perform a spike) to
observe the new capability
From observed
capability
Target
Treat as a fixed
to
variable
achieve plan
=
dja@djaa.com, @agilemanager
WIP
37. Using Little’s Law
Determines
staffing level
Calculated based on
known lead time
capability & required
At this point perhaps just a little
delivery rate
black magic and experience may
be required.
If our current working
WIP = 22
practices/process exhibited an
Rounding 22 up to 25 would
average WIP of 1 item per person then
55/week 25 people organized infor 5 teams
we require conveniently provide 5
with to complete 5 items each
teams of 5 peoplea WIP limit of the
0.4 weeks
project on-time
=
From observed
capability
Target
to
achieve plan
dja@djaa.com, @agilemanager
Treat as a fixed
variable
39. WIP in this area
should be 25
items*
*photo taken
early in the
project before it
was fully
staffed/loaded
Lead time
Median lead time
target is 2 days
Alert managers if
beyond 5 days
dja@djaa.com, @agilemanager
41. Kanban systems control variability that
affect predictability
Kanban systems defer commitments is
Committing early
improving quality of decision making
comforting but can lead to
and reducing unnecessary work and
disappointment later.
rework.
Predictability is improved!
Kanban builds trust
enabling deferred
commitment
dja@djaa.com, @agilemanager
42. Kanban enables improved agility
Replenishment & delivery cadences
are de-coupled and can be tuned to
information arrival and overhead of
the transaction.
Industries such as media
Lead time can be independent of
require the decoupled
replenishment & delivery cadence!
dynamics of kanban to react
to unfolding events
dja@djaa.com, @agilemanager
43. Kanban Improves Governance
Visualization of the kanban system
and explicit declaration of policies
improves transparency on risk
Kanban systems can
management
be
designed to align directly
There is no crystal ball gazing! Risk & gowith strategic plans
analysis is not speculative!
to-market strategies
dja@djaa.com, @agilemanager
45. About
David Anderson is a thought
leader in managing effective
software teams. He leads a
consulting, training and
publishing and event planning
business dedicated to
developing, promoting and
implementing sustainable
evolutionary approaches for
management of knowledge
workers.
He has 30 years experience in the high technology industry
starting with computer games in the early 1980’s. He has led
software teams delivering superior productivity and
quality using innovative agile methods at large companies
such as Sprint and Motorola.
David is the pioneer of the Kanban Method an agile and
evolutionary approach to change. His latest book published
in June 2012 is, Lessons in Agile Management – On the Road to
Kanban.
David is a founder of the Lean-Kanban University Inc., a
business dedicated to assuring quality of training in Lean
and Kanban for knowledge workers throughout the world.
dja@djaa.com, @agilemanager
46. Acknowledgements
A virtual kanban system was first used with an offshore team within
Microsoft’s IT department in 2004/2005. The Kanban Method as it is
known today emerged at Corbis 2006/2007.
Adoption of cumulative flow diagrams, Little’s Law, virtual kanban
systems & cost of delay were heavily influenced by Donald
Reinertsen.
Major contributors to the material in this presentation include
Daniel Vacanti, Jim Benson, Corey Ladas, Janice Linden-Reed, Troy
Magennis, Chris Matts, Olav Maassen and Julian Everett
dja@djaa.com, @agilemanager
49. impact
Cost of Delay has a 2nd Dimension
Working capital
impact
time
Working capital
impact
time
Extinction Level Event – a short delay will
completely deplete the working capital of
the business
Major Capital – the cost of delay is such
that a major initiative or project will be
lost from next year’s portfolio or
additional capital will need to be raised
to fund it
Discretionary Spending – departmental
budgets may be cut as a result or our
business misses its profit forecasts
impact
time
Intangible – delay causes embarrassment,
loss of political capital, affects brand
equity, mindshare, customer confidence, etc
?
time
dja@djaa.com, @agilemanager
51. Visualize Risks to provide Scheduling
Information
Outside:
Start Early
Market Risk
Items with the same shape carry the same risks
and should be scheduled into the kanban system
TS
at approximately the same time.
CR
It is also wise to hedge risk by
Do not
Tech Risk
Lifecycle
New
allocating prioritize items. From a whichever ones
capacityprofile pick group for
in the system of items
Spoilrisk
with the same
items of differentMidprefer most Start Late
risk profiles.Inside:
you like or
Unknown Soln
Diff Cow
Known but not us
Done it before
Commodity
Intangible
Disc
Std
Maj. Cap.
ELE
Delay Impact
dja@djaa.com, @agilemanager
FD
Expedite
Risk profile
for a work
item or
deliverable
Cost of Delay
52. Improving Liquidity through Labor Pool
Flexibility
Engineering
Ready
Teams
3
F
Cost
Reducer
s
Spoilers
2
1
3
Development
Testing
3
Verification Acceptance
Steven
Brian
Done
Ongoing
Done
flexibly across rows
on the board to keep
work flowing
G
GY
Differenti
ators
1
3
It’s typical to see splits of
Promotions from
fixed team workers versusjunior
team member to flexible
flexible system workers
Joe
Dworker with
David of between 40-60% an avatar
P1
clearly visualize why a pay
PB
DE
rise is justified. Flexible
Peter
Roughly half the labor
E
Rhonda
workers help manage
Generalist or T-shaped
pool are flexible workers
MN
people who can move
liquidity risk better!
AB
Ongoing
2
Table
Stakes
Team
LeadAnalysis
Joann
Ashok
dja@djaa.com, @agilemanager
Junior who will be rotated
through all 4 teams
53. Market Risk of Change
Profits
Market Share
etc
Start
Late
Differentiators
Spoilers
Regulatory
Changes
Cost Reducers
Scheduling
Potentia
l Value
Market Risk
Highly
likely
to
change
Table Stakes
Highly
unlikely
to change
dja@djaa.com, @agilemanager
Start
Early
54. Aligning with Strategic Position
or Go-to-Market Strategy
DeployEngineering
Ready
2
Table
Stakes
3
Cost
Reducer
s
2
Spoilers
Ongoing
3
Done
Testing
3
Verification Acceptance
∞
Market segmentation can be used to narrow the
necessary table stakes for any given market
G
niche! Enabling early delivery for narrower
markets but potentially including value
generating differentiating features
E
D
1
Differenti
ators
Development
ment
Ready
1
dja@djaa.com, @agilemanager
F
I
Done
55. Product Lifecycle Risk
High
Not well understood
High demand for innovation &
experimentation
Low
Profit
Margin
Major
Growth
Market
Investment
Product Risk
Innovative/New
Cash Cow
Low
Well understood
Low demand for
innovation
dja@djaa.com, @agilemanager
Low
High
56. Hedging Risk in a Portfolio Kanban
Horizational position shows percentage complete
Allocation of personnel
Complete
Total = 100%
0%
Cash Cows
10% budget
Innovative/New
30% budget
B
A
Growth Markets
60% budget
D
C
K
E
G
F
dja@djaa.com, @agilemanager
Complete
100%
Projects-in-progress
Color may indicate cost of
delay (or other risk)
H
57. Risk is a multi-dimensional contextual
problem
These are just useful examples!
We must develop a set of
We can easily envisage other risk dimensions risk
such as technical risk,that work in context for
taxonomies vendor dependency
risk, organizational maturity risk and so forth.
a specific business.
It may be necessary to run a workshop with
stakeholders to explore and expose the real
business risks requiring management
dja@djaa.com, @agilemanager