journey to systemic improvement

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