inspect and adapt workshop template
DESCRIPTION
This Scaled Agile Framework template is for use in the program-level Inspect and Adapt Workshop (see http://scaledagileframework.com/inspect-and-adapt). The Inspect and Adapt Workshop consists of quantitative and qualitative parts. Quantitatively, the teams demo the solution and self-assess how well they delivered features against the PSI objectives (the Release Predictability Measure) and review whatever additional program-level metrics they have agreed to. With this data in hand, the qualitative (i.e., subjective) part follows. For this, we recommend a structured “Inspect and Adapt” root cause analysis and corrective action-planning format, as we will describe in the details below. The SAFE Inspect and Adapt workshop consists of three parts: 1. The solution demo and collection of customer feedback 2. Quantitative measurement 3. The problem solving workshopTRANSCRIPT
1© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. Scaled Agile Framework ® is a trademark of Leffingwell, LLC.
Inspect and AdaptApplying the Philosophy and Discipline of “Kaizen Mind”
Training . Certification . Community
V5.3
2© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Agenda
Inspect & Adapt Context
Part 1: The PSI Solution Demo
Part 2: Quantitative Measurement
Part 3: The Problem Solving Workshop– Overview
– Root Cause Analysis (Fishbone) Diagram
– Pareto Chart
– Corrective Action Plan
3© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Inspect & Adapt Context
4© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Predictive vs. Empirical Process
If a process is too unpredictable or too complicated for the planned, (predictive) approach, then the empirical approach (measure and
adapt) is the method of choice. - Ken Schwaber
Empirical (Adaptive) Process
Proc
ess
Controls
Inpu
ts
Out
puts
Plan – measure – adapt – repeat
5© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Kaizen Mind
70% of improvement processes that require change fail, mainly due to a lack of sense of urgency amongst leadership.
- John Kotter, Harvard Business School
There is a sense of danger.
- Koki Konishi, Toyota City Technical Skills Academy
We need “kaizen mind” an unending sense of crisis behind the company’s constant drive to improve.
- Jeff Sutherland – co-creator of Scrum
Kaizen (改善 ) is Japanese for "change for the better" and refers to a philosophy of continuous improvement
The ‘Toyota Way’ Is Translated for a New Generation of Foreign Managers
by Marking Fackler, New Your Times, February, 2007
6© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Kaizen Mind Example
Excerpt from a board presentation from a high performing agile company, in year 4 of agile
7© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Kaizen Mind and Lean Thinking
– Go and See for yourself to thoroughly understand the situation
– Make decisions slowly by consensus, thoroughly considering all options; implement decisions rapidly;
– Become a learning organization through relentless reflection
– The Toyota Way
Continuously solving root problems drives organizational learning
8© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Inspect and Adapt Overview
I&A has three parts:
Part 1. The PSI demo of the solution’s current state to program stakeholders
Part 2. Quantitative measurement
Part 3. The problem solving workshop
Timebox: 3-4 hours per PSI
Inspect and Adapt (I&A) is to a Release Train what the sprint demo and retrospective are to a team
9© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Part 1: The PSI Solution Demo
Often led by product management and the system team
Attended by business owners, program stakeholders, product management, release train engineer(s), Scrum Masters, and teams
Teams demonstrate the current state of the solution to the appropriate stakeholders, thereby getting the fast feedback they need
to steer a proper course
Reprinted by Permission of Rally Software Development
10© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Part 2: Quantitative Measurements
Notes
Teams and business owners self-assess the percentage of business value they achieved for each objective
Each team’s planned vs. actual can then be rolled into the Release Predictability Report
Teams also review any other agreed to measures
As part of the PSI Solution Demo, teams compare planned vs. actual business value achieved for the PSI Objectives
Team Performance Report Other Metrics
11© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Release Predictability Report
The Release Predictability Report show whether the PSI objectives % completion falls within an acceptable process control band
Target: effective process control range
Team A: (out-of-control development)
Team B: (controlled development)Program
PSI 2 PSI 3 PSI 4PSI 1 PSI 5
120
80
60
40
20
0
100
Per
cen
t O
bje
ctiv
es A
chie
ved
12© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Establish accountability Create new stories Specify measurable results Set achievable deadlines Monitor progress
Part 3: The Problem Solving Workshop
Using root cause analysis, teams systematically address the larger impediments that are limiting velocity
Insufficiently Reliable Release Commitments?
Insufficient
architectural runway
13© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Part 1: The PSI Solution Demo
14© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Solution PSI Demo
PSI 1 Demo
1. System level demo
2. Team 1 highlights
3. Team 2 highlights
4. Team 3 highlights
5. ...
Timebox:60 minutes
(Insert any context slides and stage the
demo using this agenda)
15© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Part 2: Quantitative Measurements
16© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Team Performance Assessment
Timebox:30 minutes
How did we do? All teams’ PSI objectives were assigned a
business value from 1-10
Review and rate your release achievements
– How well did you do against your stated objectives, including (a) timeliness, (b) content, and (c) quality?
– Scale: (1-10), max being max total business value
Average these across all objectives and give yourself a program percent achievement score
17© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Other Metrics
Timebox:30 minutes
How did we do? Collect and discuss any other program
metrics that the team has agreed to collect
(Insert any context slides and stage the metrics review
using this agenda)
18© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Part 3: The Problem Solving Workshop
Overview Root Cause Analysis (Fishbone)
Diagram Pareto Chart Corrective Action Plan
19© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Establish accountability Create new stories Specify measurable results Set achievable deadlines Monitor progress
Part 3: The Problem Solving Workshop
Using root cause analysis, teams systematically address the larger impediments that are limiting velocity
Insufficiently Reliable Release Commitments?
Insufficient
architectural runway
20© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Agree on the Problem
Agree on the Problem(s) to Solve
1. Identify program issues and restate as problems– You may arrive at these through a variety of means:
• Have Scrum Masters summarize top themes which emerged in their team retrospectives and the improvement backlog items which were identified, targeted, and completed.
• Collectively discuss program issues as a group
– Restate the information you gather as succinct problem statements
2. Vote on most important
– Either select enough so each breakout group will have one, or have multiple groups work on one in parallel
3. Self organize into groups of 7 +/- 2 and select the problem your group will be analyzing
Timebox:90 minutes
21© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Part 3: The Problem Solving Workshop
Overview Root Cause Analysis (Fishbone)
Diagram Pareto Chart Corrective Action Plan
22© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Root Cause Analysis Diagram
Definition: A graphic tool used to explore and display opinion about sources of variation in a process.
– Also called a Cause-and-Effect , Ishikawa Diagram (who first used the technique in the 1960s.) or Fishbone Diagram.
Source: wikipedia
Purpose: To arrive at a few key sources that contribute most significantly to the problem being examined. – These sources are then targeted for improvement.
– Also illustrates the relationships among the wide variety of possible contributors to the effect.
The name of a basic problem of interest is entered at the right of the diagram at the end of the main "bone".
23© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Root Cause Analysis (Fishbone) Diagram
People Process
Tools Program Environment
Insufficiently Reliable Release
Commitments
Our main “bones” represent typical sources of problems
in software
24© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Root Cause Analysis Diagram, contd.
The main possible causes of the problem (the effect) are drawn as bones off of the main backbone.
The starting bones represent all possible influences.
Brainstorming is typically done to add possible causes to the main "bones" and more specific causes to the "bones" on the main "bones."
This subdivision into ever increasing specificity continues as long as the problem areas can be further subdivided.
The practical maximum depth of this tree is usually four or five levels.
When the fishbone is complete, one has a complete picture of all the possibilities about what could be the root cause for the designated problem.
Source: wikipedia
25© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
The 5 Why’s
The 5 Whys is a question-asking method used to explore the cause/effect relationships underlying a particular problem.
Ultimately, the goal of applying the 5 Whys method is to determine a root cause of a defect or problem.
A critical problem solving training component, integral to Total Quality Management
This tool is used routinely within Kaizen, lean manufacturing, and Six Sigma and TQM
The architect of the Toyota Production System, Taiichi Ohno, (Toyota Chairman) described the 5 whys method as "... ... by repeating why five times, the nature of the problem as well as its solution becomes clear.”
Source: wikipedia
26© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Example ‒ The 5 Why’s
Questioning could be taken further to a sixth, seventh, or greater level.
This would be legitimate, as the "five" in 5 Whys is not gospel; rather, it is postulated that five iterations of asking why is generally sufficient to get to a root cause.
The key is to avoid assumptions and logic traps Instead trace the chain of causality in direct increments from the
effect to a root cause that still has some connection to the problem.
My car will not start. (the problem)
Why? - The battery is dead. (first why)
Why? - The alternator is not functioning. (second why)
Why? - The alternator belt has broken. (third why)
Why? - The alternator belt was well beyond its useful service life and has never been replaced. (fourth why)
Why? - I have not been maintaining my car according to the recommended service schedule. (fifth why, root cause)
Source: wikipedia
27© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Root Cause Analysis (Fishbone) Diagram
People Process
Tools Program Environment
Insufficiently Reliable Release
Commitments
Cause 1
Cause of cause 1
Cause of cause of cause 1Cause of
cause of cause of cause 1
Cause of cause of cause of cause ofcause 1
28© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Root Cause Analysis
Create Your Fishbone Diagram Succinctly state the problem you are addressing
Create a fishbone diagram for your problem statement
Brainstorm potential causes of the problem, and place them on the chart
For each cause identified, use the 5 whys technique to get to a potential root cause
Prepare to present your result
Timebox:45 minutes
29© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Part 3: The Problem Solving Workshop
Overview Root Cause Analysis (Fishbone)
Diagram Pareto Chart Corrective Action Plan
30© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Pareto Analysis
Pareto analysis is a statistical technique in decision making that is used for selection of a limited number of tasks that produce significant overall effect.
It uses the Pareto principle – 20% of the work can generate 80% of the advantage of doing the entire job.
In terms of quality improvement, a large majority of problems (80%) are produced by a few key causes (20%).
Source: wikipedia
31© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Pareto Analysis (cont’d)
Useful where many possible courses of action are competing for your attention.
The problem-solver estimates the benefit delivered by each action, then selects a number of the most effective actions that deliver a total benefit reasonably close to the maximal possible one.
Helps stimulate thinking and organize thoughts.
Source: wikipedia
32© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Prioritize Root Causes
People Process
Tools Program Environment
Cause 1
Cause of cause 1
Cause of cause of cause 1
Cause of cause of cause of cause 1
Cause of cause 1
Insufficiently Reliable Release
Commitments
33© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Pareto Analysis
Result: a histogram of relative importance of root causes
Cause 1 Cause 2 cause 3 Cause 4 Cause 5 Cause 60
1
2
3
4
5
6
7
8
9
10
34© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Pareto Analysis
Create Your Pareto Chart
Use a cumulative voting technique to do a Pareto analysis of each identified root cause
Each team member gets 10 votes
Place your votes on as few or as many (limit 5 votes per item) root causes as appropriate
Refactor, re-aggregate causes as appropriate
Use that data to create a big visible histogram chart
Prepare to present your resultTimebox:30 minutes
Cause 1
Cause 2
cause 3
Cause 4
Cause 5
Cause 6
0123456789
10
35© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Part 3: The Problem Solving Workshop
Overview Root Cause Analysis (Fishbone)
Diagram Pareto Chart Corrective Action Plan
36© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
After we determine we have a problem, what’s next?
a. Ignore it - the problem may go away
b. Blame it on another team
c. Blame it on the business owner
d. Blame it on another program
e. Create a Corrective Action Plan
Houston, we have a problem.
Answer:e. Create a Corrective Action Plan
Houston, we have a
problem...
37© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Corrective Action Plan
What is a Corrective Action Plan anyway?
Corrective – A different course of action
Action – Active steps we can realistically accomplish
Plan – Organized, purposeful, accountable, measurable
38© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Effective Corrective Action Plans
1. State the new problem (the selected root cause) succinctly
2. Brainstorm some potential solutions
3. Break it into parts. Take responsibility
4. Specify measurable results
5. Set achievable deadlines
6. Monitor progress
Root cause of the problem
Houston, we have a plan!
Corrective Action Plan
39© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Corrective Action Plan Components
1. State the new problem clearly and succinctly
• Pick one specific root cause, i.e. the top root cause that you identified in your pareto analysis
• Restate that as the new problem
Clearly restate your problem
40© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Corrective Action Plan Components
2. Brainstorm a solution
• Brainstorm prospective solutions with the team
• Cumulative vote on suggested next steps
Brainstorm solutions
Vote on next steps
41© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Corrective Action Plan Components
3. Take responsibility
• Identify the stories you’ll need to effect the solution
• Take responsibility for stories
• Prepare to put the stories on your release plan
Know who’s owning what
42© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Corrective Action Plan Components
4. Specify measurable results
• What measures can we use to track progress?
What does progress look like?
43© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Corrective Action Plan Components
5. Set achievable deadlines
• Not too fast
• Not too slow
• Not TBD
Action 1March 16th
Action 3May 1st
Make your goals achievable
44© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Corrective Action Plan Components
6. Monitor Progress
• How will we track our action steps?
• How will we know when this is no longer the biggest problem?
• Define what “done” means for the Corrective Action Plan
Make your progress as visible as your problems
45© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Corrective Action Plan
Build Your Corrective Action Plan Pick the top root cause on your Pareto chart
Restate it as a problem
Build a corrective action plan. This will create your program improvement backlog items
Prepare to present your results to the group
Timebox:60 minutes
46© 2008 - 2013 Scaled Agile, Inc. and Leffingwell, LLC. All rights reserved.
Questions?