David Joyce of the BBC presents a Kanban experience report at Valtech's Agile Edge March 2010.

1. Kanban Overview and
Experience Report
David Joyce
BBC Worldwide
1

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

12. Bottlenecks - Stall
12

13. Bottlenecks - Vacant Space
13

14. Kanban Workflow
We ensure the right work is done at the right time,
rather than who is doing the work.
14

15. New Kind of Standup
15

16. A New Kind of Planning
Planning can be ‘de-coupled’
16

17. Releasing
Releasing can be ‘de-coupled’
17

18. Iterations
Iterative Development Without Iterations
tim
gth
e
len
18

19. Retrospectives
We have more choice on when and how to reflect and improve
19

20. De-Coupling
20

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

22. Cumulative Flow
22

23. Work Breakdown
23

24. Kanban for Everyone
24

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

26. Kanban Usage
26

27. Kanban
Summary
John Seddon - Freedom from Command & Control
27

28. Experience Report
Eric Willeke - Kanbandev Yahoo! group
28

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

36. Future Media & Technology!
36

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

47. Thank you
Questions?
John Seddon - Freedom from Command & Control