The use of virtual kanban systems in creative knowledge work and the wider Kanban Method for successful evolutionary change in your technology business - briefly explained! From the Colors in Projects conference in Bucharest, Romania, March 2013
Colors in Projects 2013 Bucharest - Kanban Briefly Explained
1. 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
2. A story to get us started
dja@djaa.com, @djaa_dja
3. 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 &
Emergency work is unplanned User Acceptance
work ishighest priority. Arrival rate
receives often 50% or greater!
& 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, @djaa_dja
Waiting for
Test
4. Capability & Customer Satisfaction
What was the observed capability of
PTCs
this department? How was customer
satisfaction?
Product
Testers
Developers
Managers delivery was 0%. There was a 100%
On-time
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 was poor!
Waiting for
Backlog
Test
dja@djaa.com, @djaa_dja
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
So controlling the unplanned,
disruptive demand would improve
Prioritized
Waiting for
predictability!
Backlog
Test
dja@djaa.com, @djaa_dja
6. What is a kanban system?
dja@djaa.com, @djaa_dja
7. A Kanban Systems consists of
“kanban” signal cards in
circulation
dja@djaa.com, @djaa_dja
8. Kanban as a solution for XIT
dja@djaa.com, @djaa_dja
9. 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, @djaa_dja
*
I
Deployment
Ready
∞
10. 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 delivery time*
75
25
* Includes queuing time prior to selection
dja@djaa.com, @djaa_dja
Time (in quarters)
11. What is a kanban system?
(& how to implement one for knowledge
work)
dja@djaa.com, @djaa_dja
13. Discard rates are often high
Pool
of
Ideas
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, @djaa_dja
Deployment
Ready
∞
14. Replenishment Frequency
Pool
of
Ideas
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, @djaa_dja
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
∞
15. Delivery Frequency
Pool
of
Ideas
Change
Requests
Pull
F F
F
F F
F
F
Engineering
Ready
Development
Test
Ready
Testing
UAT
3
5
3
∞
Ongoing
Done
Frequent deployment is
more agile.
5
Deployment buffer size can
On-demand deployment
reduce as frequency of
D deliveryagile!
most increases
G
PTCs
Discarded
I
dja@djaa.com, @djaa_dja
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
16. Specific delivery commitment may be
deferred even later
DeployEnginPool
of
Ideas
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, @djaa_dja
2nd
Commitment
point*
17. Defining Kanban System Lead Time
Pool
of
Ideas
Engineering
Ready
5
Deployment
Ready
∞
The clockTest
starts ticking when
UAT
we
customers
Ready
Development accept the Testing
is
5
∞
3 order, not when it 3 placed!
Ongoing
Done
Until then customer orders are
merely available options
Change
Requests
Pull
F F
F
F F
F
F
D
G
E
System Lead Time
PTCs
I
Discarded
I
dja@djaa.com, @djaa_dja
Lead time
ends when
the item
reaches the
first ∞
queue.
18. Flow the
Efficiency
Flow efficiency measures
Pool
Enginpercentage of total lead time
of spent actually adding value
eering
is
Development
Ideas
Ready
(or knowledge) versus waiting
3
Ongoing
2
Done
Testing
3
Verification Acceptance
Deployment
Ready
∞
Until then customer orders are
merely available options
Flow efficiency = Work Time
Multitasking means time spent
E in working columns is often
waiting time
PB
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, @djaa_dja
x 100%
Lead Time
Flow efficiencies of 2% have been
F
reported*. 5% -> 15% D normal, P1
is
>
40% is good!
G
I
Done
19. What is the Kanban Method?
dja@djaa.com, @djaa_dja
20. 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
dja@djaa.com, @djaa_dja
21. 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
dja@djaa.com, @djaa_dja
22. 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)
dja@djaa.com, @djaa_dja
26. 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
dja@djaa.com, @djaa_dja
27. 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
dja@djaa.com, @djaa_dja
32. 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
dja@djaa.com, @djaa_dja
33. Scaling up and down
(big projects, portfolios & personal work)
dja@djaa.com, @djaa_dja
34. Scaling Up - Planning a big project
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 (local average) delivery rate
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, @djaa_dja
35. 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, @djaa_dja
WIP
36. 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, @djaa_dja
Treat as a fixed
variable
38. 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, @djaa_dja
39. 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
dja@djaa.com, @djaa_dja
40. 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
dja@djaa.com, @djaa_dja
41. Hedging Investment Risk against Product
Lifecycle in a Portfolio Kanban
Horizontal position shows percentage complete
Allocation of
personnel
Total = 100%
Complete
0%
Cash Cows
10% budget
Size of ticket indicates
scale or size of project
D
C
K
E
G
F
dja@djaa.com, @djaa_dja
Complete
100%
B
A
Growth Markets
60% budget
Innovative/New
30% budget
Projects-in-progress
Color may indicate cost of
delay (or other risk)
H
43. 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, @djaa_dja
44. 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.
dja@djaa.com, @djaa_dja