2. Kanban Overview
Kanban is a transparent, work-limited,
value pulling system.
Eric Willeke - Kanbandev Yahoo! group
2
3. Start with what you do now.
Modify it slightly to implement
pull
Use a transparent method for
viewing work, and organising the
team
Limit WIP and pull work when
the team has capacity.
Evolve from there by recognising
bottlenecks, waste and
Stop Starting - Start Finishing!
variability that affect
performance
David Anderson
3
4. Work in Process
Because we want to deliver new value quickly,
we want to limit the amount of work that we
take on at one time
We want to finish items before starting others
4
5. Pull Work not Push
There is a queue of work, which goes through
a number of stages until its done.
5
6. Kanban Pull
Backlog Step 1 Step 2 Step n Done
In In In
Process Process Process
Flow
6
7. Kanban Pull With Limits
That looks very like a typical Agile Task Board.
However, there is one more important element which
really defines a Kanban system - limits.
There are two basic limits
WIP limits and Queue limits
7
8. WIP Limits
Governs the maximum number of work items
that can be in that state at any instant
8
9. Queues and Queue Limits
A queue distinguishes work that is eligible to
be pulled, from work that is still in process.
The queue allows for slack
9
10. Queues and Limits
Backlog Step 1 Step 2 … Step n Done
Queue In In In
Process Queue Process Queue Process
(3) (2)
…
10
11. Leading Indicators
Agile development has long rallied around “inspect and adapt”.
Early agile methods built their feedback around velocity.
This is a trailing indicator.
With the regulating power of limits, it tells you about problems
in your process, while you are experiencing the problem!
11
21. Metrics
Metrics are a tool for everybody
The team is responsible for its metrics
Metrics allow for continuous improvement
Red, Amber, Green is not enough.
21
25. Lean Decision Filter
1. Value trumps flow
Expedite at the expense of flow to maximise value
2. Flow trumps waste elimination
Increase WIP, if required to maintain flow, even though it may add waste
3. Eliminate waste to improve efficiency
25
29. Kanban began
in one product
team in mid 2008
Continually evolving... 29
30. Kanban began
in one product
team in mid 2008
Continually evolving... 30
31. The Kanban “flu”
soon spreads to
other teams
Application Support
32. The Kanban “flu”
soon spreads to
other teams
Application Support
Pro duct Teams
32
33. The Kanban “flu”
soon spreads to
other teams
Application Support
Pro duct Teams
Design Team
33
34. The Kanban “flu”
soon spreads to
other teams
Application Support
Pro duct Teams
Design Team
CO TS Team
34
35. Now entering new
territory
Had looked at Agile before
small team sizes didn’t
fit
specialisation
constant mix of new
development & support
irregular release
cadence
35
37. No Single Solution Recipe for success
Focus on Quality
Based on a set of Reduce WIP, Deliver
principles Often
Better practice NOT Balance Demand against
best practice Throughput
Prioritise
Coupled with sound Reduce variability
engineering practices
and a team willing to Let the data tel
l yo u,
reflect, adapt and what to do w ith
the data
improve
Control
Statistical
David Anderson
37
38. Mean reduced from 22 to 14 days (33%)
Lead Time 50% drop in the spread in variation.
Each of the outliers were proved to be special cause.
38 Data split at financial year end and in July
39. Mean reduced from 9 to 3 days (67%)
77% drop in the spread in variation.
Development Time The major reduction factor has been to limit work in
process.
39 Data split at financial year end and in July
40. Reduction in lead and cycle times, and increase in
throughput are not at the expense of quality.
# Live Defects Number of live bugs is within statistical control, and
seeing a reduction since July.
40 Data split at end and in July
41. Mean reduced from 25 to 5 days (81%)
Large drop in the spread in variation.
# Days Blocked The outliers was proved to be special cause, waiting
for a 3rd party. # blockers actually increased.
41 Data split at financial year end and in July
42. Upward trend. Rising to almost every working day.
Throughput Expected as code base is decoupled, work items
broken into MMFs, and cycle time reduces.
43. 43
Scrum to Kanban
Data split at end and in July
Mean reduced from 10 to 4 days (60%)
Engineering Time 64% drop in the spread in variation.
44. Kanban
Summary
John Seddon - Freedom from Command & Control
45. Scrumban
Scrumban is useful for existing Scrum
teams, who are looking to improve their
scale or capability
45
46. More information on Kanban
My blog http://leanandkanban.wordpress.com/
Kanban community site http://www.limitedwipsociety.org
Kanban for Software Engineering http://bit.ly/hz9Ju
Soon to be published academic paper on BBCW and Kanban case study
46
