David Anderson Kanban Briefly Explained

Kanban
Successful Evolutionary Change

for your Technology Business
What is Kanban?
How do you implement it?
What are the benefits?
Color in Projects
Bucharest, March 2013
dja@djaa.com, @djaa_dja
A story to get us started
Microsoft 2004 - the XIT Story
Change requests
PTCs
Requests for estimates of future work
Product are often “invisible”, have an
Managers Developers
unpredictable Testers
arrival rate & are given
priority.
Discard rate of estimated

Emergency future work
work is unplanned &User Acceptance
is often
receives 50%priority.
highest or greater!
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 Waiting for

Backlog Test
Capability & Customer Satisfaction
What was the observed capability of
PTCsdepartment? How was customer
this
Product satisfaction?
Managers Developers Testers
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, average 5
months, slow 1 year plus.
But everything had a business case and was

prioritized by ROI!
Budgets were well governed but

Prioritized customer satisfaction
Waiting for was poor!
Backlog Test
What Were the Issues?
So what issues affected the outcome?
PTCs
Why were governance policies so
Product disruptive?
Managers Developers Testers
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
So controlling the unplanned, disruptive

Prioritizeddemand would improve
Waiting for predictability!
Backlog Test
What is a kanban system?
A Kanban Systems consists of
“kanban” signal cards in
circulation
Kanban as a solution for XIT
A virtual kanban system was chosen
Engin- Deploy-
eering Test ment
Backlog Development Ready Testing UAT Ready
Ready
Ongoing
3 Done
5 3 ∞ ∞
5
Change
Requests
It‟s important to realize the process for
Pull software development did not
Pull B change.
The kanban system is an overlay on the
FF
F G
existing process.Pull
It changes C
scheduling
F F and prioritization only
F G
F F D
*
PTCs
PTCs are permitted to break the
I
kanban limit
*Blocked to service PTC
240% The Results Backlog depleted.
CRs improvement Serving at rate of
in delivery demand
rate
50
30
10
Time (in quarters)

90% drop in end-to-
Time to Resolve
125 end delivery time*

Average
75
25
Time (in quarters)

* Includes queuing time prior to selection
What is a kanban system?
(& how to implement one for knowledge work)
Kanban are virtual!
Engin- Deploy-
eering Test ment
Backlog Development Ready Testing UAT Ready
Ready
Ongoing
3 Done
5 3 ∞ ∞
5
Change
Requests
Pull Pull B
F J These are the virtual kanban
F G Pull C
F F
Boards
F are not required to do Kanban!
I
F F The boardDis a visualization of the
The first system used database triggers
workflow process, the work-in-progress
*
to signal pull. There was no board! and the kanban

PTCs
Commitment is deferred
Engin- Deploy-
eering Test ment
Backlog
Pool Development Ready Testing UAT Ready
Ready
of Ongoing
3 Done
5 3 ∞ ∞
Ideas 5
Change Items in the backlog remain

Requests
optional and unprioritized
Pull
FF
F D
F F E
F G
F Wish to avoid discard after commitment
PTCs We are committing to getting

started. We are certain we want
to take delivery.
Commitment point I
Discard rates are often high
Engin- Deploy-
eering Test ment
Ready
of Ongoing
3 Done
5 3 ∞ ∞
Ideas 5
The discard rate with XIT was
Change
48%. ~50% is commonly observed.
Requests
Deferring commitment and
FF
avoiding
Options interrupting
have value because the
F D futurefor
workers is uncertain
estimates makes
F
G 0%sense when
discard discard
E thererates
rate implies is no are
Reject high!
uncertainty about the future
PTCs
Discarded I
I
Upstream Kanban Prepares Options
Pool Ready
Biz Requi- Comm-
of for Development Testing
Case rements itted
Ideas Engin-
Dev Analysis 3 3
eering
4 Ongoing Done
∞ 24 - 48 12 - 24 4 - 12 Verification
Min & Max limits K

J
insure sufficient L
options are always
available I D
F
Options Committed Work
$$$ cost of acquiring options
Discarded
Reject
P Q
O
Commitment point
Replenishment Frequency
Engin- Deploy-
eering Test ment
Ready
of 3 5 3 ∞ ∞
Frequent replenishment is
Ongoing Done
Ideas 5
Replenishment
more agile.
Change
Requests
Pull
On-demand replenishment is
FF
F D most agile!
F F
F G E
F
The frequency of system
PTCs replenishment should reflect
arrival rate of new information
and the transaction &
coordination costs of holding a
Discarded I
meeting
I
Delivery Frequency
Engin- Deploy-
eering Test ment
Ready
of 3 5 3 ∞ ∞
Frequent deployment is more
Ongoing Done
Ideas 5
Delivery
agile.
Change
Requests
Pull Deployment buffer size can
On-demand deployment
reduce as frequency of deliveryis
FF
F D most agile!
increases
F F
F G E
F
The frequency of delivery should

PTCs
reflect the transaction &
coordination costs of
deployment plus costs &
Discarded
toleranceI of customer to take
I delivery
Specific delivery commitment may be
Engin-
deferred even later Deploy-
eering Test ment
Ready
of Ongoing
3 Done
5 3 ∞ ∞
Ideas 5
Change
Requests
Pull
FF
F D
F F
F G E
F
We are now committing to a
PTCs specific deployment and delivery
date
*This may happen earlier if

Discarded I 2nd
circumstances demand it
I Commitment
point*
Defining Kanban System Lead Time
Engin- Deploy-
The clock starts
Test ticking when we ment
eering
Pool Ready
accept theReady
Development customers order,UAT
Testing not Ready
of 3 when5 it is placed!
3 ∞ ∞
Ongoing Done
Ideas 5
Until then customer orders are
Change merely available options
Requests
Pull
FF Lead time
F D
F F ends when
F G E the item
F
System Lead Time reaches the
first ∞
PTCs queue.
Discarded I
I
Little’s Law & Cumulative Flow
WIP
Delivery Rate =
Lead Time
Pool Ready
of Avg. Lead Time To
Ideas Deploy
WIP Avg. Delivery Rate
Infinite Queues Decouple Systems
Pool Engin- Deploy-
of infinite
eering ment
The queue Development
decouples Testing
Ideas Ready Ready Done
the systems. The deployment
3 Done 3
Ongoing
system uses
2 batches and is Verification Acceptance
∞
separate from the kanban
system
F
The 2nd commitment is D MN
actually a commitment
PB for P1
the downstream deployment

system G E
AB
DE
The Kanban System gives us
confidence to make that
I
downstream commitment
GY
2nd Commitment point

Identifying Buffers
Pool Engin- Deploy-
of eering ment
Development Testing Ready
Ideas Ready Done
3 3
Ongoing Done verification Acceptance
2 ∞
F I am a buffer!
D P1
G The clue is is
inin
my
The clue
E myname
name––
“…
PB “…Ready”
Ready”
I GY DE MN
AB
I am buffering non-instant
availabilityororanactivity
availability activitywith
witha a
cyclical cadence
Defining Customer Lead Time
Engin- Deploy-
eering Test ment Done
Ready
of Ongoing
3 Done
5 3 ∞ ∞ ∞
Ideas 5 The clock still starts ticking
when we accept the customers
Change order, not when it is placed!
Requests
Pull
FF
F D
F F
F G E
F
Customer Lead Time
PTCs
The frequency of delivery

cadence will affect customer lead
timeI in addition to system
Discarded
I capability
Flow Efficiency
Flow efficiency measures the
Pool Engin-
percentage of total lead time is Deploy-
of eering adding value (or ment
spent actually Development Testing
Ideas Ready Ready Done
knowledge) versus waiting
3 3
Ongoing Done Verification Acceptance
2 ∞
Until then customer orders are
merely available optionsFlow efficiency = Work Time x 100%
Lead Time
Flow efficiencies of 2% have been
F
reported*. 5% -> 15% D is normal,
> 40%
P1
Multitasking means time spent
G is good!
PB
E in working columns is often
waiting time
I GY DE MN
AB
Waiting Working Waiting Working Waiting
Lead Time
* Zsolt Fabok, Lean Agile Scotland, Sep 2012, Lean Kanban France, Oct 2012
Observe Lead Time Distribution as an enabler
of a Probabilistic Approach to Management
Lead Time Distribution
3.5
2.5
CRs & Bugs
1.5
0.5
8
1
8
15
22
29
36
43
50
57
64
71
78
85
92
99
10
11
12
12
13
14
14
Days
This is multi-modal data!
The SLA
workexpectation
is of two types:of
Mean of 31 Change 105
Requests
days (new features);
with 98 % on-time
days and Production Defects
SLA expectation of
44 days with 85% on-time
Filter Lead Time data by Type of Work (and
Class of Service) to get Single Mode Distributions
Production Defects
Change Requests
Mean 98% at Mean 98% at

5 days 25 days 50 days 150 days
85% at 85% at
10 days 60 days
Allocate Capacity to Types of Work
Pool Engin- Deploy-
of eering ment
Ideas Ready Development Testing Ready Done
3 3
Ongoing Done Verification Acceptance
2 ∞
Change
Requests 4
E allocation
Consistent capacity
F should bring some
more consistency
MN to
D
delivery rate of work
AB of each type
PB Lead Time
DE
Production
Defects 3
G P1
I
GY
Separate
Separate understanding
understanding of
of Lead
Lead Time
Time forfor each
each type
type of work
of work
Lead Time
The Optimal Time to Start
If we start too early, we forgo the
impact
option and opportunity to do
something else that may provide
value.
If we start too late we risk

Ideal Start When we
incurring the cost of delay 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
Metrics for Kanban Systems
Cumulative flow integrates demand,

WIP, approx. avg. lead time and delivery
rate capabilities
Lead time histograms show us actual

lead time capability
Flow efficiency, value versus failure

demand (rework), initial quality, and
impact of blocking issues are also useful
Questions?
and
Break
What is the Kanban Method?
Kanban Method
A management & cultural approach to

improvement
View creative knowledge work as a set of

services
Encourages a management focus on

demand, business risks and capability of
each service to supply against that
demand
The Kanban Method is not…
A project management or software

development lifecycle process
Nor, does it encourage a process-centric

approach to improvement!
Don’t do this!...
Designs
Or
Management Imposes Defines Process
Coaches
Process
Follow
Workers
Kanban Method
Uses visualization of invisible work and

virtual kanban systems
Installs evolutionary “DNA” in your

organization
Enables adaptability to respond

successfully to changes in your business
environment
6 Practices for Evolutionary DNA
The Generalized Version
Visualize
Limit Work-in-progress
Manage Flow
Make Policies Explicit
Implement Feedback Loops
Improve Collaboratively, Evolve Experimentally
(using models & the scientific method)
Kanban Kata
Feedback Loops
The Kanban Kata

Operations
Review
Improvement
Kata
Standup
Meeting
Standup Meeting
Disciplined conduct
and acts of leadership
lead to improvement
opportunities
Kaizen events happen

at after meetings
Improvement Kata
A mentor-mentee relationship
Usually (but not always) between a superior and a sub-ordinate
A focused discussion about system capability
Definition of target conditions
Discussion of counter-measures – actions taken to improve

capability
Operations Review
Meet monthly
Disciplined review of
demand and capability for
each kanban system
Provides system of
systems view and
understanding
Kaizen events suggested

by attendees
6 Practices for Evolutionary DNA
The More Specific Version
Visualize work, workflow & business risks

(using large physical or electronic boards in communal spaces)
Implement Virtual Kanban Systems
Manage Flow
Make Policies Explicit
Implement Kanban Kata
Educate your workforce to enable collaborative
evolvution of policies & ways of working
based on models of workflow from bodies of knowledge such as
Theory of Constraints, Deming‟s Profound Knowledge, Lean,
Risk Management such as Option Theory
Scaling out across an
organization
Treat each service separately
Observed
Capability
Demand
Observed
Capability
Demand
Observed
Capability
Demand
Some systems have dependencies on
others
Observed
Capability
Demand
Observed
Capability
Demand
Observed
Capability
Demand
Organizational Improvements Emerge
Scaling Kanban
Each Kanban System is designed from
first principles around a service provided
Scale out in a service-oriented fashion
Do not attempt to design a grand

solution at enterprise scale
The Kanban Kata are essential!
Allow a better system of systems to

emerge over time
Scaling up and down
(big projects, portfolios & personal work)
Scaling up
(large projects, 2-tiered systems)
Scaling Up - Planning a big project
Device Management Ike II Cumulative Flow
Required (local average) delivery rate
240
220
200
180
160
Features
140 Slope in middle

120 3.5x - 5x slope
100
at ends 5x
80
60
40
20
0
2006 2008
ar
ar
eb
eb
eb
ar
ar
ar
M
-M
-M
-M
-F
-F
-F
2-
9-
10
17
24
16
23
30
During the middle 60% Time
of the project schedule we
need Throughput (velocity) to average 220 features
Inventory Started Designed Coded Complete
per month
Little’s Law Determines
staffing level
Calculated based on
known lead time
capability & required
Plandelivery
based on Changing theobserved
currently
rate WIP limit without
capability maintaining
and current the staffing level ratio
working
practices. Dorepresents a change
not assume processto the way of
improvements.
WIP
working. It is a change to the
process and will produce a change
Delivery
If changingRate
WIP =
into
the observed
reduce „common cause‟
undesirable
capabilityget
of the
newsystem
effects (e.g. multitasking),
sample data (perform a spike) to
Lead Time
observe the new capability
From observed
capability
Target
to Treat as a fixed
achieve plan variable
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 average
WIP of 1 itemRounding 22then
per person up to
we25 would
55/week
require 25 people=
conveniently provide
organized in 5for 5 teams
with ato
WIP limit ofthe
5 items each
teams of 5 people complete
project on-time
0.4 weeks
From observed
capability
Target
to Treat as a fixed
achieve plan variable
2-tiered board
Kanban System within a Kanban System
1 lane per team
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
Scaling Down - Personal Kanban
A mutation that emerged in my office in

2008 by Jim Benson & Corey Ladas
For individuals & small teams (2 or 3 ppl)
Visualize
Limit WIP
Simple To Do-Next-Doing-Done boards
Scaling Up - Portfolio Kanban
Another mutation that emerged in 2009

in various places such as mobile.de in Berlin
Focus on limiting projects in a portfolio
No real workflow
Visualize project completion through

physical position of ticket
Visualize business risks
Hedging Risk in a Portfolio Kanban
Horizational position shows percentage complete
Allocation of personnel
Total = 100% Complete Complete
Projects-in-progress
0% 100%
Cash Cows B
10% budget A
Size of ticket indicates
scale or size of project
Growth Markets
60% budget C D
Innovative/New E K
30% budget G
F H
Color may indicate urgency
(or some other risk)
Summary of Benefits
Collaboration Benefits
Shared language for improved

collaboration
Shared understanding of dynamics of flow
Emotional engagement through

visualization and tactile nature of boards
Greater empowerment (without loss of

control)
Tangible Business Benefits
Improved predictability of lead time and

delivery rate
Reduced rework
Improved risk management
Improved agility
Improved governance
Organizational Benefits
Improved trust and organizational social

capital
Improved organizational maturity
Emergence of systems thinking
Management focused on system capability

through policy definition
Adaptability
(to shifts in demand and risks under management)
Thank you!
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
About
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.
Acknowledgements
Hakan Forss of Avega Group in Stockholm has been instrumental in

defining the Kanban Kata and evangelizing its importance as part of a
Kaizen culture.
Real options & the optimal exercise point as an improvement over

“last responsible moment” emerged from discussions with Chris Matts,
Olav Maassen and Julian Everett around 2009.
The inherent need for evolutionary capability that enables

organizational adaptation was inspired by the work of Dave Snowden.
David J Anderson
& Associates, Inc.
Appendix
Example Distributions
Expedite
Standard
Intangible
Fixed Date

David Anderson Kanban Briefly Explained

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

David Anderson Kanban Briefly Explained

Uploaded by

Copyright:

Available Formats

Kanban

Successful Evolutionary Change

Discard rate of estimated

Prioritized Waiting for

But everything had a business case and was

Budgets were well governed but

Entire backlog was planned & commitments

Expedite policy for PTCs was folklore – no one

So controlling the unplanned, disruptive

*Blocked to service PTC

Time (in quarters)

125 end delivery time*

Time (in quarters)

to signal pull. There was no board! and the kanban

Change Items in the backlog remain

PTCs We are committing to getting

Min & Max limits K

The frequency of delivery should

*This may happen earlier if

the downstream deployment

2nd Commitment point

The frequency of delivery

Waiting Working Waiting Working Waiting

This is multi-modal data!

Mean 98% at Mean 98% at

If we start too late we risk

With a 6 in 7 chance of on-time

Cumulative flow integrates demand,

Lead time histograms show us actual

Flow efficiency, value versus failure

A management & cultural approach to

View creative knowledge work as a set of

Encourages a management focus on

A project management or software

Nor, does it encourage a process-centric

Uses visualization of invisible work and

Installs evolutionary “DNA” in your

Enables adaptability to respond

The Generalized Version

The Kanban Kata

Kaizen events happen

Usually (but not always) between a superior and a sub-ordinate

A focused discussion about system capability

Definition of target conditions

Discussion of counter-measures – actions taken to improve

Kaizen events suggested

The More Specific Version

Visualize work, workflow & business risks

Scale out in a service-oriented fashion

Do not attempt to design a grand

The Kanban Kata are essential!

Allow a better system of systems to

140 Slope in middle

1 lane per team

Median lead time

A mutation that emerged in my office in

For individuals & small teams (2 or 3 ppl)

Simple To Do-Next-Doing-Done boards

Another mutation that emerged in 2009

Focus on limiting projects in a portfolio

Visualize project completion through

Visualize business risks

Shared language for improved

Shared understanding of dynamics of flow