journey to systemic improvement lean exchange dec 2009 david j
Post on 13-May-2015
918 Views
Preview:
TRANSCRIPT
A Journey to Systemic Improvement
David JoyceBBC Worldwide
1
Kanban
Kanban is a transparent, work-limited, value pulling system.
Eric Willeke - Kanbandev Yahoo! group
2
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.
Stop Starting - Start Finishing!Evolve from there by recognising bottlenecks, waste and variability
that affect performance
David Anderson
3
Continually evolving...
Kanban began in one product
team in mid 2008
4
Continually evolving...
Kanban began in one product
team in mid 2008
4
Continually evolving...
Kanban began in one product
team in mid 2008
Dev limits
4
Continually evolving...
Kanban began in one product
team in mid 2008
Handoff
4
Continually evolving...
Kanban began in one product
team in mid 2008
5
Continually evolving...
Kanban began in one product
team in mid 2008
Engineering Done
5
Continually evolving...
Kanban began in one product
team in mid 2008
Batched Releases
5
Continually evolving...
Kanban began in one product
team in mid 2008
MMFs
5
Continually evolving...
Kanban began in one product
team in mid 2008
Ideation Board
5
Continually evolving...
Kanban began in one product
team in mid 2008
Goals & Objectives
5
Continually evolving...
Kanban began in one product
team in mid 2008
Express Lane
5
Continually evolving...
Kanban began in one product
team in mid 2008
Hidden Work
5
Continually evolving...
Kanban began in one product
team in mid 2008
Dependencies
5
Continually evolving...
Kanban began in one product
team in mid 2008
Systest Constraint
5
Application Support
The Kanban “flu”soon spreads to
other teams
6
Application Support
The Kanban “flu”soon spreads to
other teams
Classes of service
6
Application Support
The Kanban “flu”soon spreads to
other teams
Estimation
6
Application Support
The Kanban “flu”soon spreads to
other teams
T-Shirt Sizing
6
Application Support
The Kanban “flu”soon spreads to
other teams
Standard Work
6
Application Support
The Kanban “flu”soon spreads to
other teams
Order point
6
Application Support
The Kanban “flu”soon spreads to
other teams
Large Standup
6
Application Support
Product Teams
The Kanban “flu”soon spreads to
other teams
7
Application Support
Product Teams
The Kanban “flu”soon spreads to
other teams
2nd Product Team
7
Application Support
Product Teams
The Kanban “flu”soon spreads to
other teams
MMF Breakdown
7
Application Support
Product Teams
The Kanban “flu”soon spreads to
other teams
MMF Queue
7
Application Support
Product Teams
The Kanban “flu”soon spreads to
other teams
Reduced Board Size
7
Application Support
Product Teams
Design Team
The Kanban “flu”soon spreads to
other teams
8
Application Support
Product Teams
Design Team
The Kanban “flu”soon spreads to
other teams
Design Board 1
8
Application Support
Product Teams
Design Team
The Kanban “flu”soon spreads to
other teams
Design Board 2
8
Application Support
Product Teams
Design Team
The Kanban “flu”soon spreads to
other teams
Design Board 3
8
Application Support
Product Teams
Design Team
COTS Team
The Kanban “flu”soon spreads to
other teams
9
Application Support
Product Teams
Design Team
COTS Team
The Kanban “flu”soon spreads to
other teams
COTS Main Board
9
Application Support
Product Teams
Design Team
COTS Team
The Kanban “flu”soon spreads to
other teams
3rd Party Board
9
Had looked at Agile before
small team sizes didn’t fit
specialisation
constant mix of new development & support
irregular release cadence
Now entering newterritory
10
Had looked at Agile before
small team sizes didn’t fit
specialisation
constant mix of new development & support
irregular release cadence
Now entering newterritory
Excel Board
10
Had looked at Agile before
small team sizes didn’t fit
specialisation
constant mix of new development & support
irregular release cadence
Now entering newterritory
First Board
10
11
Programme Board
WIP Board
11
Future Media & Technology!
!"#$%&'()*
Blockers
11
Future Media & Technology!
!"#$%&'(')*#+,#-'#&+'
.*+%*-/0'1.&2&,.,3'
"45*.6%4%&78'
Future Media & Technology!
!"#$%&'()*
Kaizen Board
11
Future Media & Technology!
!"#$%&'(')*#+,#-'#&+'
.*+%*-/0'1.&2&,.,3'
"45*.6%4%&78'
Future Media & Technology!
!"#$%&'()*
Winter Olympics Board
11
No Single Solution
Based on a set of principles
Better practice NOT best practice
Focus on Quality
Reduce WIP, Deliver Often
Balance Demand against Throughput
Prioritise
Recipe for success
David Anderson
Coupled with sound engineering practices and a team willing to reflect, adapt and
improve
Reduce variability
Statistical Control
Let the data tell you,what to do with the data
12
Lead Time
Mean reduced from 22 to 14 days (33%)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
Development Time
Mean reduced from 9 to 3 days (67%)77% drop in the spread in variation.The major reduction factor has been to limit work in process.
Data split at financial year end and in July
14
# Live Defects
Reduction in lead and cycle times, and increase in throughput are not at the expense of quality. Number of live bugs is within statistical control, and seeing a reduction since July.
Data split at end and in July
15
# Days Blocked
Mean reduced from 25 to 5 days (81%)Large drop in the spread in variation.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
Scrum to Kanban
Engineering Time
Mean reduced from 10 to 4 days (60%)64% drop in the spread in variation.
Data split at end and in July
17
Systems Thinking
The means to obtain knowledge, and act with prediction and confidence of
improvement.
John Seddon - Freedom from Command & Control
18
If we build an IT system around a wasteful process, then we are locking in that process for longer
Projects often focus on the needs of a single business unit
Often IT develop solutions based on
sub optimised status quo
Software
Project
Kanban encourages a whole “system” view rather than a
locally optimised IT view
Are we just building
the wrong thing righter?
David Anderson & Dr. Peter Middleton
19
Sale
s
Mar
ket
ing
Fin
ance
HR IT
Upper Management
20
Sale
s
Mar
ket
ing
Fin
ance
HR IT
Upper Management
20
Sale
s
Mar
ket
ing
Fin
ance
HR IT
Upper Management
Hidden costs
20
Sale
s
Mar
ket
ing
Fin
ance
HR IT
Upper Management
Hidden costs
NEEDS I.T.
20
Sale
s
Mar
ket
ing
Fin
ance
HR IT
Upper Management
Hidden costs
Flow
Outsidein
20
Since IT “can”should it?
There is little merit in a well executed project that no one
wants the output from.
Dr. Peter Middleton
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.
21
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.
The thing that makes technology work is not the technology
Tripp Babbitt
22
Understand
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
Improve
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
Failure demand
Design System around these
Eliminate Causes
Clean flow
Act on the system conditions impeding flow
Set work clean
John Seddon
24
Can IT further improvethis process or system?
Now we can see potential benefits, from a position of knowledge, about the work.
We can therefore predict the benefits IT solutions will bring
The result is always less investment in IT, and much more
value from it
IT is pulled into the work, rather than dictating the way work
works
John Seddon
25
Measure improvement results
Use operationalperformance data
Split dataafter a change
26
Pull IT
Measure
Improve the work
Understand System
A better method for IT
27
Pull IT
Measure
Improve the work
Understand System
A better method for IT
27
To be continued...
Toyota say they still have 70% waste in their system
28
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
Any Questions ?
I must understand the system, improve the work, THEN pull ITI must understand the system, improve the work, THEN pull ITI must understand the system, improve the work, THEN pull ITI must understand the system, improve the work, THEN pull ITI must understand the system, improve the work, THEN pull IT
30
top related