2024: Domino Containers - The Next Step. News from the Domino Container commu...
Journey To Systemic Improvement Lean Exchange Dec 2009 David J
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
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
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
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
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
