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
Product Managers
PTCs Requests for estimates of future work are often invisible, have an Testers Developers unpredictable arrival rate & are given priority. Discard rate of estimated future work Emergency work is unplanned & User Acceptance is often 50% or greater! 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
Waiting for Test
Capability & Customer Satisfaction

What was the observed capability of PTCs this department? How was customer satisfaction? 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, average 5 months, slow 1 year plus. But everything had a business case and was prioritized by ROI! Budgets were well governed but customer satisfaction was poor! Waiting for Test
Prioritized Backlog
What Were the Issues?

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 So what issues affected the outcome? PTCs Why were governance policies so disruptive? Testers Developers
So controlling the unplanned, disruptive Prioritized demand 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

Backlog
Engineering Ready Development
Ongoing
5
Change Requests
Test Ready
Done
Testing
UAT
Deployment Ready
Pull
FF F F F F F
Its important to realize the process for B change. software development did not Pull The kanban system is an overlay on the existing process.Pull It changes C scheduling G and prioritization only
PTCs
PTCs are permitted to break the kanban limit *Blocked to service PTC
50 30 10
240% improvement in delivery rate
CRs
The Results
Backlog depleted. Serving at rate of demand
Average Time to Resolve
Time (in quarters)

125 75 25
90% drop in end-toend delivery time*
* Includes queuing time prior to selection

Time (in quarters)
(& how to implement one for knowledge work)
What is a kanban system?
Kanban are virtual!

Backlog
Engineering Ready Development
Ongoing
5
Change Requests
Test Ready
Done
Testing
UAT
Deployment Ready
Pull
B Pull These are the virtual kanban F J G C F Pull F F Boards are not required to do Kanban! F I F The boardD is a visualization of the F * 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
Backlog Pool of Ideas
Change Requests
Engineering Ready
Development
Ongoing
Test Ready
Done
Testing
UAT
Deployment Ready
Pull
Items in the backlog remain optional and unprioritized
FF F F F F F
D
G
Wish to avoid discard after commitment

We are committing to getting started. We are certain we want to take delivery.
PTCs
Commitment point
Discard rates are often high

Pool of Ideas
Change Requests
Engineering Ready
Development
Ongoing
Test Ready
Done
Testing
UAT
Deployment Ready
FF F F
Reject
PTCs
Deferring commitment and Options have value because the avoiding interrupting is uncertain D future workers for estimates makes E there sense when discard rates discard rate implies is no are G 0% uncertainty about the future high!
The discard rate with XIT was 48%. ~50% is commonly observed.
Discarded
I
Upstream Kanban Prepares Options

Pool of Ideas
Biz Case Dev
Requirements Analysis
24 - 48
12 - 24
Ready for Engineering
Committed
Development
4 - 12
Testing
Ongoing
Done
Verification
Min & Max limits insure sufficient options are always available
K L
I
F
Options $$$ cost of acquiring options

Discarded
Committed Work
Reject
O
Q
Commitment point
Replenishment Frequency
Pool of Ideas Engineering Ready Development
Ongoing
Replenishment
Pull
Change Requests
Frequent replenishment is more agile.

Done
Test Ready
Testing
UAT
Deployment Ready
FF F F F F F
On-demand replenishment is D most agile!

G
E
The frequency of system replenishment should reflect arrival rate of new information and the transaction & coordination costs of holding a I meeting
PTCs
Discarded
I
Delivery Frequency
Pool of Ideas
Change Requests
Engineering Ready
Development
Ongoing
5 Frequent deployment is more agile.

Done
Test Ready
Testing
UAT
Deployment Ready
Delivery
Pull
FF F F F F F
Deployment buffer size can On-demand deployment reduce as frequency of deliveryis D most increases agile!
E
The frequency of delivery should reflect the transaction & coordination costs of deployment plus costs & toleranceI of customer to take delivery
PTCs
Discarded
I
Specific delivery commitment may be deferred even later DeployEnginPool of Ideas

Change Requests
eering Ready
Development
Ongoing
Test Ready
Done
Testing
UAT
ment Ready
Pull
FF F F F F F
D
G
E
We are now committing to a specific deployment and delivery date
PTCs
Discarded
I
*This may happen earlier if I circumstances demand it
2nd Commitment point*
Defining Kanban System Lead Time

Pool of Ideas
Change Requests
Engineering Ready
Ongoing
The clock starts Test ticking when we Testing accept the customers order,UAT not Ready Development when 3 5 it is placed! 3
Done
Deployment Ready
Until then customer orders are merely available options
Pull
FF F F F F F
D
G
System Lead Time
PTCs
Lead time ends when the item reaches the first queue.
Discarded
I
Littles Law & Cumulative Flow

Delivery Rate
WIP
Lead Time
Pool of Ideas
Avg. Lead Time

WIP
Ready To Deploy
Avg. Delivery Rate
Infinite Queues Decouple Systems

Pool Enginof infinite eering The queue Development decouples Ideas Ready
the systems. The deployment 3 Done Ongoing system uses batches and is 2 separate from the kanban system
Testing
Verification Acceptance
Deployment Ready
Done
F The 2nd commitment is actually a commitment PB for the downstream deployment system
The Kanban System gives us confidence to make that I downstream commitment
GY
DE
D G
MN
P1
AB
2nd Commitment point

Identifying Buffers
Ongoing
Testing
verification Acceptance
Done
Deployment Ready
Done
G
GY
PB DE
The clue is is inin my name The clue name E my Ready Ready

MN AB
P1
I am a buffer!
I am buffering non-instant availability or activity with aa availability or an activity with cyclical cadence
Defining Customer Lead Time

Pool of Ideas
Change Requests
Engineering Ready
Development
Ongoing
Test Ready
The clock still starts ticking when we accept the customers order, not when it is placed!
Done
Testing
UAT
Deployment Ready
Done
Pull
FF F F F F F
PTCs
D
G
Customer Lead Time

The frequency of delivery cadence will affect customer lead I in addition to system time capability
Discarded
I
Pool Enginpercentage of total lead time is of eering adding value (or spent actually Development Ideas Ready
Flow Efficiency Flow efficiency measures the

knowledge) versus waiting 3
2
Ongoing
Testing
Done
Deployment Ready
Done
Until then customer orders are merely available options Flow efficiency = Work Time Flow efficiencies of 2% have been F reported*. 5% -> 15% D is normal, P1 > 40% G is good!
100%
Lead Time
Multitasking means time spent E in working columns is often waiting time
MN AB
GY
PB DE
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 3 2.5
CRs & Bugs
2 1.5 1 0.5 0
1 14
15
22
29
36
43
50
57
64
71
78
85
92
99
10
11
12
12
13
Days
This is multi-modal data!
Mean of 31 days
of The SLA workexpectation is of two types: Change 105 Requests (new features); days with 98 % on-time and Production Defects SLA expectation of 44 days with 85% on-time
14
Filter Lead Time data by Type of Work (and Class of Service) to get Single Mode Distributions
Production Defects
Change Requests
Mean 5 days
98% at 25 days
85% at 10 days
Mean 50 days 85% at 60 days
98% at 150 days
Allocate Capacity to Types of Work

Ongoing
2
Change Requests
Testing
Done
Deployment Ready
Done
E allocation Consistent capacity should bring some to more consistency MN D AB of each type delivery rate of work
PB DE
Lead Time
Production Defects
G
GY
P1
Separate understanding of Separate understanding of Lead Lead Time each type of work Time forfor each type of work
Lead Time
The Optimal Time to Start

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
Here
impact
When we need it
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? Break
and
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!
Dont do this!...
Designs Or Defines
Management
Imposes
Process Coaches
Process
Workers
Follow
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
(using models & the scientific method)
Improve Collaboratively, Evolve Experimentally
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, Demings 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
(big projects, portfolios & personal work)
Scaling up and down
(large projects, 2-tiered systems)
Scaling up
Scaling Up - Planning a big project

Device Management Ike II Cumulative Flow
Required (local average) delivery rate
240 220 200 180 160 140 120 100 80 60 40 20 0
Features
Slope in middle 3.5x - 5x slope at ends
5x
2M ar
9M ar
eb
eb
eb
16 -M ar
23 -M ar
During the middle 60% of the project schedule we Time need Throughput (velocity) to average 220 features Inventory Started Designed Coded Complete per month
30 -M ar
2006
2008
10 -F
17 -F
24 -F
Littles Law
Determines staffing level
Calculated based on known lead time capability & required Changing the WIP limit without Plandelivery based on currently observed rate staffing level ratio capability maintaining and current the working represents a change to the way of practices. Do not assume process working. It is a change to the improvements. process and will produce a change Delivery Rate into the observed common cause If changing WIP reduce undesirable capabilityget of the system effects (e.g. multitasking), new Lead Time sample data (perform a spike) to observe the new capability From observed capability Target Treat as a fixed to variable achieve plan
WIP
Using Littles Law
Determines staffing level
practices/process exhibited an average 22 up to 25 would WIP of 1 itemRounding per person then we conveniently provide 55/week require 25 people organized in 5for 5 teams with ato WIP limit of 5 items each teams of 5 people complete the 0.4 weeks project on-time
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
Target to achieve plan
From observed capability Treat as a fixed 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 Complete Total = 100% 0% Complete 100%
Projects-in-progress B
Cash Cows 10% budget Growth Markets 60% budget Innovative/New 30% budget
Size of ticket indicates scale or size of project

C D
E
F
G
Color may indicate urgency (or some other risk) H
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!
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 1980s. 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
Intangible
Fixed Date
Standard

David Anderson - Kanban Briefly Explained

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

David Anderson - Kanban Briefly Explained

Diunggah oleh

Hak Cipta:

Format Tersedia

Kanban

Successful Evolutionary Change for your Technology Business

A story to get us started

Microsoft 2004 - the XIT Story

Waiting for Test

Capability & Customer Satisfaction

What Were the Issues?

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

240% improvement in delivery rate

Backlog depleted. Serving at rate of demand

Average Time to Resolve

Time (in quarters)

90% drop in end-toend delivery time*

* Includes queuing time prior to selection

Time (in quarters)

(& how to implement one for knowledge work)

What is a kanban system?

Kanban are virtual!

Items in the backlog remain optional and unprioritized

Wish to avoid discard after commitment

Discard rates are often high

Upstream Kanban Prepares Options

Biz Case Dev

Ready for Engineering

Options $$$ cost of acquiring options

Frequent replenishment is more agile.

On-demand replenishment is D most agile!

5 Frequent deployment is more agile.

Specific delivery commitment may be deferred even later DeployEnginPool of Ideas

*This may happen earlier if I circumstances demand it

2nd Commitment point*

Defining Kanban System Lead Time

Until then customer orders are merely available options

System Lead Time

Littles Law & Cumulative Flow

Avg. Lead Time

Avg. Delivery Rate

Infinite Queues Decouple Systems

2nd Commitment point

The clue is is inin my name The clue name E my Ready Ready

Defining Customer Lead Time

Customer Lead Time

Flow Efficiency Flow efficiency measures the

Observe Lead Time Distribution as an enabler of a Probabilistic Approach to Management

CRs & Bugs

This is multi-modal data!

Mean 50 days 85% at 60 days

98% at 150 days

Allocate Capacity to Types of Work

The Optimal Time to Start

Metrics for Kanban Systems

Lead time histograms show us actual lead time capability

What is the Kanban Method?

The Kanban Method is not

Enables adaptability to respond successfully to changes in your business environment

6 Practices for Evolutionary DNA

Improve Collaboratively, Evolve Experimentally

Provides system of systems view and understanding

6 Practices for Evolutionary DNA

Scaling out across an organization

Treat each service separately