Part one of this talk revolves around a series of experience reports following the introduction of Kanban at the BBC in mid 2008. Part two of this talk summarises Systems Thinking, how it can be of benefit, and how Kanban has led to it being applied within BBC Worldwide.

1. A Journey to Systemic
Improvement
David Joyce
BBC Worldwide
1

2. Kanban
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
Stop Starting - Start Finishing! bottlenecks, waste and variability
that affect performance
David Anderson
3

4. Kanban began
in one product
team in mid 2008
Continually evolving...
4

5. Kanban began
in one product
team in mid 2008
Continually evolving...
4

6. Kanban began
Dev limits in one product
team in mid 2008
Continually evolving...
4

7. Kanban began
in one product
team in mid 2008
Handoff
Continually evolving...
4

8. Kanban began
in one product
team in mid 2008
Continually evolving...
5

9. Kanban began
Engineering Done one product
in
team in mid 2008
Continually evolving...
5

10. Kanban began
in one product
team in mid 2008
Batched Releases
Continually evolving...
5

11. Kanban began
MMFs in one product
team in mid 2008
Continually evolving...
5

12. Kanban began
in one product
team in mid 2008
Ideation Board
Continually evolving...
5

13. Kanban began
in one product
team in mid 2008
Goals & Objectives
Continually evolving...
5

14. Kanban began
in one product
team in mid 2008
Express Lane
Continually evolving...
5

15. Kanban began
in one product
team in mid 2008
Hidden Work
Continually evolving...
5

16. Kanban began
in one product
team in mid 2008
Dependencies
Continually evolving...
5

17. Kanban began
in one product
team in mid 2008
Systest Constraint
Continually evolving...
5

18. The Kanban “flu”
soon spreads to
other teams
Application Support
6

19. The Kanban “flu”
soon spreads to
Classes of service
other teams
Application Support
6

20. The Kanban “flu”
soon spreads to
Estimation
other teams
Application Support
6

21. The Kanban “flu”
soon spreads to
other teams
Application Support
T-Shirt Sizing
6

22. Standard Work The Kanban “flu”
soon spreads to
other teams
Application Support
6

23. The Kanban “flu”
soon spreads to
other teams
Application Support
Order point
6

24. The Kanban “flu”
soon spreads to
other teams
Large Standup
Application Support
6

25. The Kanban “flu”
soon spreads to
other teams
Application Support
Pro duct Teams
7

26. The Kanban “flu”
soon spreads to
other teams
2nd Product Team
Application Support
Pro duct Teams
7

27. The Kanban “flu”
soon spreads to
other teams
Application Support
MMF Breakdown Pro duct Teams
7

28. The Kanban “flu”
soon spreads to
other teams
Application Support
Pro duct Teams
MMF Queue
7

29. The Kanban “flu”
soon spreads to
other teams
Application Support
Pro duct Teams
Reduced Board Size
7

30. The Kanban “flu”
soon spreads to
other teams
Application Support
Pro duct Teams
Design Team
8

31. The Kanban “flu”
soon spreads to
other teams
Application Support
Pro duct Teams
Design Team
Design Board 1
8

32. The Kanban “flu”
soon spreads to
other teams
Application Support
Pro duct Teams
Design Team
Design Board 2
8

33. The Kanban “flu”
soon spreads to
other teams
Application Support
Pro duct Teams
Design Team
Design Board 3
8

34. The Kanban “flu”
soon spreads to
other teams
Application Support
Pro duct Teams
Design Team
CO TS Team
9

35. The Kanban “flu”
soon spreads to
other teams
Application Support
Pro duct Teams
Design Team
CO TS Team
COTS Main Board
9

36. The Kanban “flu”
soon spreads to
other teams
Application Support
Pro duct Teams
Design Team
CO TS Team
3rd Party Board
9

37. 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
10

38. Now entering new
territory
Excel Board
Had looked at Agile before
small team sizes didn’t
fit
specialisation
constant mix of new
development & support
irregular release
cadence
10

39. Now entering new
territory
First Board
Had looked at Agile before
small team sizes didn’t
fit
specialisation
constant mix of new
development & support
irregular release
cadence
10

40. 11

41. Programme Board
WIP Board
11

42. Blockers
Future Media & Technology!
11

43. Kaizen Board
Future Media & Technology!
11

44. Winter Olympics Board
Future Media & Technology!
11

45. 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
12

46. 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.
Data split at financial year end and in July
13

47. 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.
Data split at financial year end and in July
14

48. 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.
Data split at end and in July
15

49. 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.
Data split at financial year end and in July
16

50. 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.
17

51. Systems Thinking
The means to obtain knowledge, and
act with prediction and confidence of
improvement.
John Seddon - Freedom from Command & Control
18

52. Kanban encourages a whole
Are we just building
“system” view rather than a
he wrong th ing righter?
t locally optimised IT view
Often IT develop
solutions based on
sub optimised status quo
are
Softw
t
Projec
Projects often focus on the
needs of a single business unit
If we build an IT system around
a wasteful process, then we are
locking in that process for longer
David Anderson & Dr. Peter Middleton
19

53. Sales
Marketing
Finance
HR
Upper Management
IT
20

54. Sales
Marketing
Finance
HR
Upper Management
IT
20

55. Upper Management
Marketing
Finance
Sales
HR
IT
Hidden costs
20

56. Upper Management
.T.
S I
ED
Marketing
N E
Finance
Sales
HR
IT
Hidden costs
20

57. Upper Management
Flow
Marketing
Outside
Finance
Sales
HR
IT
in
Hidden costs
20

58. There is little merit in a well
Since IT “can” executed project that no one
sho uld it?
wants the output from.
Focus on customer needs, and the
organisation as a system
Many of the previous problems,
that apparently required
software projects, may well have
been ‘dissolved’
The improvement effort can be
targeted to where it has most benefit.
Dr. Peter Middleton
21

59. The thing that makes technology
work is not the technology
Does this mean the end of IT?
There is a better way to approach the
use of IT.
Understand and improve, then ask if IT
can further improve.
Larger gains can be achieved through better thinking
around the design and management of work.
Then pulling IT into the work as needed.
Tripp Babbitt
22

60. Un derstan d
Purpose - look outside in
Learn about
nature of demands (in customer terms)
response to demand
causes of failure demand
capability and predictability
flow - end to end
23

61. Impro ve
Improve performance without
using IT
If the current work uses IT then
leave it in place, work with it, or
treat it as a constraint Don’t do anything to change
the IT
Value demand Clean flow
Design System Set work clean
aro un d these
Failure demand Act on the system
Eliminate Causes conditions impeding flow
John Seddon
24

62. Can IT further impro ve
this process or system?
Now we can see potential
benefits, from a position of
knowledge, about the work.
We can therefore predict the The result is always less
investment in IT, and much more
benefits IT solutions will bring
value from it
IT is pulled into the work, rather
than dictating the way work
works
John Seddon
25

63. Measure improvement results
Use o perationa
l
perfor mance d
ata
Split data
after a change
26

64. A better m etho d for IT
System
Un de rstan d
Me asure
Pull IT
Improve the work
27

65. A better m etho d for IT
System
Un de rstan d
Me asure
Pull IT
Improve the work
27

66. To be continued...
Toyota say they still have 70% waste in
their system
28

67. 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
More information on Systems Thinking
Understanding variety of demand http://bit.ly/tnnmI
Freedom from Command and Control http://bit.ly/1OUCnS
Economies of Flow http://bit.ly/tGw3U
29

68. Any Questions ?
I must understand the system, improve the work, THEN pull IT
I must understand the system, improve the work, THEN pull IT
I must understand the system, improve the work, THEN pull IT
I must understand the system, improve the work, THEN pull IT
I must understand the system, improve the work, THEN pull IT
30