lean as a scrum troubleshooter - agile alliance · a3 problem solving across multiple teams page 6...

crj@systematic.dk

Lean as a Scrum Troubleshooter

Carsten Ruseng Jakobsen

Tom Poppendieck

High Velocity Organizations* Improve and adapt faster than competitors

August 11 Copyright©2011 Poppendieck.LLC

2

1. Use well defined team work processes

designed to reveal failure rapidly.

2. Whenever failure occurs, the team swarms the

problem close in space

and time to the event.

3. Teams are expected to share what they learn

with the rest of the organization

4. The primary responsibility of leaders and

managers: make sure 1, 2, & 3 happen.

*Steven Spear - The High-Velocity Edge:

How Market Leaders Leverage Operational Excellence to Beat the Competition

Improvement Kata

August 11 Copyright©2011 Poppendieck.LLC

3

1. Visualize perfection

2. Have a first hand grasp of the situation

3. Define a target condition on the way to perfection

(Strive to move step-by-step to the target)

4. As obstacles are encountered, they are systematically

understood and overcome

Mike Rother – Toyota Kata

Vision Next Target

Condition

Current Condition

Obstacle

Problems

PDCA

1 2 3

4

Problem-Solving A3

August 11 Copyright©2011 Poppendieck.LLC

4

For boundary-spanning problems

Develop a Consensus for Action

Boundary-spanning Communication

30 Second Glance /10 Minutes to Read

Pull-Based Authority

Agreement of those affected by the change

Owner Responsibility

Team Collaboration

See also Durward Sobek & Art Smalley: Understanding A3 Thinking; and John Shook: Managing to Learn

August 11 Copyright©2011 Poppendieck.LLC

Issue: Owner: Date:

Why Does the Issue Matter: Get the attention of those affected by the issue Motivate Changes in behavior Explain why this issue Matters

o Show its impact on important goals o Use concise tables or graphs o Be sure you have the real issue

Indicate where in our process do we encounter this issue o Consider using a value stream map o Estimate the amount of waste or failure

demand How much can we expect to improve?

Test your model: Define quick experiments to confirm your model

o How will you measure improvements? o How much change does your model

predict? Gain a consensus on the countermeasures with

those who will need to participate. What do the actual results Tell you about your

model o Does the problem go away o Do we need to change our model?

If so, define additional experiments

Root Cause Model: Discuss with those with knowledge or data Look together for the reason behind the issue Use 5 Whys, Fishbone, or Cause/Effect diagrams Focus of your analysis

o Look for system shortcomings, not blame o You have reached a root cause when

You identify Bad Assumptions You identify Faulty Reasoning

o Consensus on the ultimate cause Refine your initial description why it matters

and how much improvement is achievable.

Adjustments: What changes in the way you do your work do

the results of the experiment justify? How will you ensure the problem does not

recur? What further work do you need to do to

improve your model or attempt further countermeasures?

A S

imp

le A

3 P

rob

lem

So

lving

Tem

pla

te

$Revis

ion: 1.1

$

A3 problem solving across multiple teams

Page 6

Prerequisites • Teams work according to a

shared workflow or process

• Shared root cause analysis with participants from the teams facing the problem

• Each team take ownership of a subset of root causes and establish counter measures for them

• Management facilitation

Impact • Cross-team problems are often

harder and will often be rooted in systemic issues in the organisation

• take longer to understand and solve

• requires management commitment

• But for the same reasons the payoff for such improvements are significant larger than smaller problems within single projects

Creates even stronger results than A3 problem solving in a single project

$Revis

ion: 1.1

$

Page 7

$$

Revis

ion:

$

READY – Flow of Story Implementation

Based on opportunity

Easy to communicate symptom

Shared root causes across projects

Clear target

Counter measures work

Adopt Ready-Ready in all projects!

Improvement duration 9 month!

$Revis

ion: 1.1

$

Case – Feature clarification

Page 8

Clear?

Fishbone analysis – all projects

Initially 20 counter measures

failed re-asses root cause(s)

Check!

Adopt!

$Revis

ion: 1.1

$

Systematic experience

Page 9

Key measures: • Fix time for failed build must be less

than a work day

• Development flow of stories at least 60%

• Sprint test and delivery at most 10% of schedule

• Ready velocity > Done velocity

• Co-loated teams 4-8 people

Practice

• Learn from failures and successes

• Shared analysis of root causes brings focus on systemic problems

• Fishbone, interviews, 5xwhy, …

• Jidoka: Respect that those who do the job, are those who can best improve it

• Ask people to solve own problems - ask not people to solve others problems!

• Continue until countermeasures are verified and measure effect

Key points from larger improvements implemented the past 5 years

$Revis

ion: 1.1

$

Page 10

Questions

$Revis

ion: 1.1

$

Page 11

$$

Revis

ion:

$

Continous Integration – Fix time for failed build

$Revis

ion: 1.1

$

Page 12

$$

Revis

ion:

$

READY – Flow of Story Implementation

$Revis

ion: 1.1

$

Page 13

$$

Revis

ion:

$

$Revis

ion: 1.1

$

Page 14

$$

Revis

ion:

$

Sprint Zero – Efficient agile initiation of project

$Revis

ion: 1.1

$

Page 15

$$

Revis

ion:

$

Efficient collaboration with customer on feature clarification