inspect and adapt workshop template

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

[email protected]

V5.3


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


Inspect & Adapt Context


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


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

http://www.nytimes.com/2007/02/15/business/worldbusiness/15toyota.html?pagewanted=all


Kaizen Mind Example

Excerpt from a board presentation from a high performing agile company, in year 4 of agile


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


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



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


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


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


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


Solution PSI Demo

PSI 1 Demo

1. System level demo

2. Team 1 highlights



5. ...

Timebox:60 minutes

(Insert any context slides and stage the

demo using this agenda)


Part 2: Quantitative Measurements


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


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)



Overview Root Cause Analysis (Fishbone)

Diagram Pareto Chart Corrective Action Plan


Establish accountability Create new stories Specify measurable results Set achievable deadlines Monitor progress


Using root cause analysis, teams systematically address the larger impediments that are limiting velocity

Insufficiently Reliable Release Commitments?

Insufficient

architectural runway


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


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".


Root Cause Analysis (Fishbone) Diagram

People Process

Tools Program Environment

Insufficiently Reliable Release

Commitments

Our main “bones” represent typical sources of problems

in software


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


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


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


Root Cause Analysis (Fishbone) Diagram

People Process



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


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


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


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


Prioritize Root Causes

People Process


Cause 1

Cause of cause 1

Cause of cause of cause 1

Cause of cause of cause of cause 1

Cause of cause 1


Commitments


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


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


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...


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


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 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



2. Brainstorm a solution

• Brainstorm prospective solutions with the team

• Cumulative vote on suggested next steps

Brainstorm solutions

Vote on next steps



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



4. Specify measurable results

• What measures can we use to track progress?

What does progress look like?



5. Set achievable deadlines

• Not too fast

• Not too slow

• Not TBD

Action 1March 16th

Action 3May 1st

Make your goals achievable



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



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


Questions?

inspect and adapt workshop template

Technology