Upload
agileyorkshire
View
809
Download
0
Tags:
Embed Size (px)
DESCRIPTION
David Joyce - Presentation To AgileYorkshire
Citation preview
Kanban Overview and Experience Report
David JoyceBBC Worldwide
1Monday, 7 December 2009
Kanban Overview
Kanban is a transparent, work-limited, value pulling system.
Eric Willeke - Kanbandev Yahoo! group
2Monday, 7 December 2009
Use a transparent method for viewing work, and organising the
team
Start with what you do now.
Modify it slightly to implement pull
David Anderson3Monday, 7 December 2009
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
Start with what you do now.
Modify it slightly to implement pull
David Anderson3Monday, 7 December 2009
Work in Process
4Monday, 7 December 2009
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
4Monday, 7 December 2009
Pull Work not Push
5Monday, 7 December 2009
Pull Work not Push
There is a queue of work, which goes through a number of stages until its done.
5Monday, 7 December 2009
Kanban Pull
Step 1 DoneStep 2 Step nBacklogIn
ProcessIn
ProcessIn
Process
6Monday, 7 December 2009
Kanban Pull
Step 1 DoneStep 2 Step nBacklogIn
ProcessIn
ProcessIn
Process
Flow
6Monday, 7 December 2009
Kanban Pull
Step 1 DoneStep 2 Step nBacklogIn
ProcessIn
ProcessIn
Process
Flow
6Monday, 7 December 2009
Kanban Pull With Limits
7Monday, 7 December 2009
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 limitsWIP limits and Queue limits
7Monday, 7 December 2009
WIP Limits
8Monday, 7 December 2009
WIP Limits
Governs the maximum number of work items that can be in that state at any instant
8Monday, 7 December 2009
Queues and Queue Limits
9Monday, 7 December 2009
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
9Monday, 7 December 2009
Queues and Limits
…
Step 1 DoneStep 2 Step n…BacklogIn
Process QueueIn
Process QueueIn
Process
10Monday, 7 December 2009
Queues and Limits
…
Step 1 DoneStep 2 Step n…BacklogQueue In
Process QueueIn
Process QueueIn
Process(3) (2)
10Monday, 7 December 2009
Queues and Limits
…
Step 1 DoneStep 2 Step n…BacklogQueue In
Process QueueIn
Process QueueIn
Process(3) (2)
10Monday, 7 December 2009
Queues and Limits
…
Step 1 DoneStep 2 Step n…BacklogQueue In
Process QueueIn
Process QueueIn
Process(3) (2)
10Monday, 7 December 2009
Queues and Limits
…
Step 1 DoneStep 2 Step n…BacklogQueue In
Process QueueIn
Process QueueIn
Process(3) (2)
10Monday, 7 December 2009
Queues and Limits
…
Step 1 DoneStep 2 Step n…BacklogQueue In
Process QueueIn
Process QueueIn
Process(3) (2)
10Monday, 7 December 2009
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!
11Monday, 7 December 2009
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!
11Monday, 7 December 2009
Bottlenecks - Stall
12Monday, 7 December 2009
Bottlenecks - Stall
12Monday, 7 December 2009
Bottlenecks - Vacant Space
13Monday, 7 December 2009
Bottlenecks - Vacant Space
13Monday, 7 December 2009
Kanban Workflow
14Monday, 7 December 2009
Kanban Workflow
We ensure the right work is done at the right time, rather than who is doing the work.
14Monday, 7 December 2009
New Kind of Standup
15Monday, 7 December 2009
New Kind of Standup
15Monday, 7 December 2009
A New Kind of Planning
16Monday, 7 December 2009
A New Kind of Planning
Planning can be ‘de-coupled’
16Monday, 7 December 2009
Releasing
17Monday, 7 December 2009
Releasing
Releasing can be ‘de-coupled’
17Monday, 7 December 2009
Iterations
Iterative Development Without Iterations
18
length
time
Monday, 7 December 2009
Iterations
Iterative Development Without Iterations
18
length
time
Monday, 7 December 2009
Retrospectives
19Monday, 7 December 2009
Retrospectives
We have more choice on when and how to reflect and improve
19Monday, 7 December 2009
De-Coupling
20Monday, 7 December 2009
De-Coupling
20Monday, 7 December 2009
Metrics
21
Metrics are a tool for everybody
The team is responsible for its metrics
Metrics allow for continuous improvement
Red, Amber, Green is not enough.
Monday, 7 December 2009
Metrics
21
Metrics are a tool for everybody
The team is responsible for its metrics
Metrics allow for continuous improvement
Red, Amber, Green is not enough.
Monday, 7 December 2009
Cumulative Flow
22Monday, 7 December 2009
Cumulative Flow
22Monday, 7 December 2009
Work Breakdown
23
Monday, 7 December 2009
Work Breakdown
23
Monday, 7 December 2009
Kanban for Everyone
24Monday, 7 December 2009
Kanban for Everyone
24Monday, 7 December 2009
25
Lean Decision Filter
Monday, 7 December 2009
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
Monday, 7 December 2009
Kanban Usage
26
Monday, 7 December 2009
Kanban Usage
26
Monday, 7 December 2009
Kanban
John Seddon - Freedom from Command & Control
Summary
27Monday, 7 December 2009
Experience Report
Eric Willeke - Kanbandev Yahoo! group
28Monday, 7 December 2009
Kanban began in one product
team in mid 2008
29Monday, 7 December 2009
Continually evolving...
Kanban began in one product
team in mid 2008
29Monday, 7 December 2009
Continually evolving...
Kanban began in one product
team in mid 2008
29Monday, 7 December 2009
Continually evolving...
Kanban began in one product
team in mid 2008
29Monday, 7 December 2009
Continually evolving...
Kanban began in one product
team in mid 2008
29Monday, 7 December 2009
Continually evolving...
Kanban began in one product
team in mid 2008
29Monday, 7 December 2009
Continually evolving...
Kanban began in one product
team in mid 2008
29Monday, 7 December 2009
Continually evolving...
Kanban began in one product
team in mid 2008
29Monday, 7 December 2009
Continually evolving...
Kanban began in one product
team in mid 2008
29Monday, 7 December 2009
Continually evolving...
Kanban began in one product
team in mid 2008
29Monday, 7 December 2009
Continually evolving...
Kanban began in one product
team in mid 2008
30Monday, 7 December 2009
Continually evolving...
Kanban began in one product
team in mid 2008
30Monday, 7 December 2009
Continually evolving...
Kanban began in one product
team in mid 2008
30Monday, 7 December 2009
Continually evolving...
Kanban began in one product
team in mid 2008
30Monday, 7 December 2009
Continually evolving...
Kanban began in one product
team in mid 2008
30Monday, 7 December 2009
Continually evolving...
Kanban began in one product
team in mid 2008
30Monday, 7 December 2009
Continually evolving...
Kanban began in one product
team in mid 2008
30Monday, 7 December 2009
Continually evolving...
Kanban began in one product
team in mid 2008
30Monday, 7 December 2009
Continually evolving...
Kanban began in one product
team in mid 2008
30Monday, 7 December 2009
The Kanban “flu”soon spreads to
other teams
Monday, 7 December 2009
Application Support
The Kanban “flu”soon spreads to
other teams
Monday, 7 December 2009
Application Support
The Kanban “flu”soon spreads to
other teams
Monday, 7 December 2009
Application Support
The Kanban “flu”soon spreads to
other teams
Monday, 7 December 2009
Application Support
The Kanban “flu”soon spreads to
other teams
Monday, 7 December 2009
Application Support
The Kanban “flu”soon spreads to
other teams
Monday, 7 December 2009
Application Support
The Kanban “flu”soon spreads to
other teams
Monday, 7 December 2009
Application Support
The Kanban “flu”soon spreads to
other teams
Monday, 7 December 2009
Application Support
Product Teams
The Kanban “flu”soon spreads to
other teams
32Monday, 7 December 2009
Application Support
Product Teams
The Kanban “flu”soon spreads to
other teams
32Monday, 7 December 2009
Application Support
Product Teams
The Kanban “flu”soon spreads to
other teams
32Monday, 7 December 2009
Application Support
Product Teams
The Kanban “flu”soon spreads to
other teams
32Monday, 7 December 2009
Application Support
Product Teams
The Kanban “flu”soon spreads to
other teams
32Monday, 7 December 2009
Application Support
Product Teams
Design Team
The Kanban “flu”soon spreads to
other teams
33Monday, 7 December 2009
Application Support
Product Teams
Design Team
The Kanban “flu”soon spreads to
other teams
33Monday, 7 December 2009
Application Support
Product Teams
Design Team
The Kanban “flu”soon spreads to
other teams
33Monday, 7 December 2009
Application Support
Product Teams
Design Team
The Kanban “flu”soon spreads to
other teams
33Monday, 7 December 2009
Application Support
Product Teams
Design Team
COTS Team
The Kanban “flu”soon spreads to
other teams
34Monday, 7 December 2009
Application Support
Product Teams
Design Team
COTS Team
The Kanban “flu”soon spreads to
other teams
34Monday, 7 December 2009
Application Support
Product Teams
Design Team
COTS Team
The Kanban “flu”soon spreads to
other teams
34Monday, 7 December 2009
Now entering newterritory
35Monday, 7 December 2009
Had looked at Agile before
Now entering newterritory
35Monday, 7 December 2009
Had looked at Agile before
small team sizes didn’t fit
specialisation
constant mix of new development & support
irregular release cadence
Now entering newterritory
35Monday, 7 December 2009
Had looked at Agile before
small team sizes didn’t fit
specialisation
constant mix of new development & support
irregular release cadence
Now entering newterritory
35Monday, 7 December 2009
Had looked at Agile before
small team sizes didn’t fit
specialisation
constant mix of new development & support
irregular release cadence
Now entering newterritory
35Monday, 7 December 2009
Had looked at Agile before
small team sizes didn’t fit
specialisation
constant mix of new development & support
irregular release cadence
Now entering newterritory
35Monday, 7 December 2009
36Monday, 7 December 2009
36Monday, 7 December 2009
36Monday, 7 December 2009
Future Media & Technology!
!"#$%&'()*
36Monday, 7 December 2009
Future Media & Technology!
!"#$%&'(')*#+,#-'#&+'
.*+%*-/0'1.&2&,.,3'
"45*.6%4%&78'
Future Media & Technology!
!"#$%&'()*
36Monday, 7 December 2009
Future Media & Technology!
!"#$%&'(')*#+,#-'#&+'
.*+%*-/0'1.&2&,.,3'
"45*.6%4%&78'
Future Media & Technology!
!"#$%&'()*
36Monday, 7 December 2009
No Single Solution
Based on a set of principles
Better practice NOT best practice
David Anderson
Coupled with sound engineering practices and a team willing to reflect, adapt and
improve
37Monday, 7 December 2009
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
37Monday, 7 December 2009
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
37Monday, 7 December 2009
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
Let the data tell you,what to do with the data
37Monday, 7 December 2009
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
37Monday, 7 December 2009
38Monday, 7 December 2009
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 July38Monday, 7 December 2009
39Monday, 7 December 2009
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 July39Monday, 7 December 2009
40Monday, 7 December 2009
# 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 July40Monday, 7 December 2009
41Monday, 7 December 2009
# 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 July41Monday, 7 December 2009
Throughput
Upward trend. Rising to almost every working day.Expected as code base is decoupled, work items broken into MMFs, and cycle time reduces.
Monday, 7 December 2009
Scrum to Kanban
43
Monday, 7 December 2009
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
43
Monday, 7 December 2009
Kanban
John Seddon - Freedom from Command & Control
Summary
Monday, 7 December 2009
Scrumban
45
Scrumban is useful for existing Scrum teams, who are looking to improve their
scale or capability
Monday, 7 December 2009
Scrumban
45
Scrumban is useful for existing Scrum teams, who are looking to improve their
scale or capability
Monday, 7 December 2009
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
Monday, 7 December 2009
Thank you
John Seddon - Freedom from Command & Control
Questions?
Monday, 7 December 2009