Post on 05-Jun-2020
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