kanban overview and experience report

Post on 13-May-2015

809 Views

Category:

Technology

0 Downloads

Preview:

Click to see full reader

DESCRIPTION

David Joyce - Presentation To AgileYorkshire

TRANSCRIPT

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

top related