We need “kaizen mind”, an unending sense of crisis behind the company’s constant drive to improve.

– Jeff Sutherland – co-creator of Scrum

 

 

Inspect & Adapt Abstract

The philosophy and discipline of “Kaizen mind” is integral to Agile development (Agile Manifesto:….at regular intervals, team the reflects on how to become more effective…..) and Lean Thinking (Kaizen is one of the three pillars of our House of Lean). One way the Framework exhibits this is through the Inspect and Adapt (I&A) workshop held at the end of each PSI. I&A is to a Release Train what the sprint demo and retrospective are to a team—a regular, programmatic, time to reflect, problem solve, and take on improvement actions identify actions needed to increase the velocity, quality and reliability of the next increment.

As part of the I&A, teams demonstrate the current state of solution to the appropriate stakeholders, thereby getting the fast feedback they need to need to steer a proper course. This is followed by a retrospective and problem solving workshop. Because many of the challenges faced by Agile teams are rooted at the program level, stakeholders who attend this workshop should be the principals who are empowered to effect change. The result of the workshop is a set of improvement stories that can be added to the program’s next PSI backlog, which can then be immediately incorporated during release planning the next day.

Details

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 workshop

Each of these elements will be further discussed in the details below.

The Solution Demo and Collection of Customer Feedback

During the solution demo, the teams demonstrate the new Features of the solution as well as system conformance to Nonfunctional Requirements to the appropriate stakeholders, typically in a 60 – 90 minute timebox. The demo is often conducted members of Product Management, Product Owners and the System Team.

By demonstrating the current state of the system, the program gains the immediate feedback it needs to steer a proper course. This information is used as input into the next Release Planning meeting, where updates to the Vision, Roadmap, and Program Backlog are presented. It is also used as input into the problem-solving workshop which follows.

Quantitative Measurement

A primary quantitative measurement for each PSI is the Release Predictability Measure (RPM), which is a comparison of actual to plan business value achieved in the PSI. To calculate the measure, business owners and the teams subjectively assess the percentage of business value they achieved for each PSI Objective that was set in the prior planning meeting, as is illustrated in Figure 1.

Figure 1. Plan versus actual for one team's PSI objectives

Each team’s result is then rolled up to an aggregate that reflects the programs overall performance relative to plan. The business objective is to have the program performing in an acceptable process control range, as illustrated in Figure 2.

Figure 2. Target control range for Release/PSI Predictability Measure

Achieving this range means that the program can largely be depended on doing what it said it would do, and that’s a major element in building trust in the teams, program and process.

There are usually additional, program-level metrics that have also been agreed upon. These are reviewed and discussed. One such example appears in Figure 3.

Figure 3. One Release Train's PSI metrics

Note: For more information on quantitative measurements of program, project, and process agility, see ASR [1] Chapter 13 and SSA [2] Chapter 22.

The Problem Solving Workshop

The next session is a qualitative retrospective of the data that has been presented, followed by a problem solving workshop. Participants, ideally including most all members of the program and other key stakeholders, identify whatever program issues they would like to address that were identified in the retrospective. They then break into self-selecting groups, each of whom develops a corrective action plan for the problem identified. Corrective action plans are reviewed by the group as a whole. The final result is a set of program improvement stories that get added to the next days program planning backlog.

To achieve this, we recommend a structured, root cause analysis workshop format. Root cause analysis is a set of problem solving tools used to identify the root causes of a problem, rather than simply addressing the obvious symptoms. Because many of the challenges faced by agile teams are rooted at the program level, stakeholders who attend this workshop should be the people who are empowered to effect change. The session is typically facilitated by the Release Train Engineer in a timebox of three hours or less.

The root cause analysis workshop format consists of the following steps:

  1. Agree on the problem(s) to solve
  2. Apply root cause analysis tools
  3. Identify the biggest root cause
  4. Create a corrective action plan

Agree on the Problem(s) to Solve

As a group, members of the program identify key problems and impediments the program is facing. They then have a choice of resolving team level problems within their own teams, or selecting a program problem statement and joining others who wish to work on the same issue.

Apply Root Cause Analysis tools

We recommend the use of traditional and effective problem solving tools including Fishbone Diagrams, the Five Whys, and Pareto Analysis.

Fishbone Diagram

Also known as an Ishikawa Diagram, the fishbone diagram is a visual tool used to explore the causes of specific events or sources of variation in a process.

As can be seen in Figure 4, the name of the problem statement is written to the right at the end of the “backbone”.

Figure 4. Fishbone diagram with major sources identified

Causes are identified and then placed grouped into major categories as bones off the main bone. For our software-related problem solving workshop, we preload the main bones with the categories “People,” “Process,” “Tools,” “Program,” and “Environment.” However, these may be adapted as appropriate. Team members then brainstorm factors that they think contribute to the problem to be solved. Once a cause is identified, its root cause is identified with the 5 Whys technique. By simply asking Why, as many as five times, each cause of a cause is easier to discover and is added to the diagram.

Identify the Biggest Root Cause

Pareto Analysis, also known as “the 80/20 rule,” is a statistical decision making technique that is used to narrowing down the number of actions that produce the most significant overall effect. It uses the principle that 20% of the root causes can cause 80% of the problems. It is particularly useful when many possible courses of action are competing for attention, which is almost always the case with complex, systemic problems.

Once all the possible causes of causes have been identified, team members then cumulatively vote on the item they think is the biggest factor causing the end problem. They can do this by placing stars (five stars each are allocated, so they can vote on more than one root cause) on the causes they think are most problematic. The team then creates a Pareto chart, such as the example in Figure 5, which illustrates their collective consensus on the largest root causes.

Figure 5. Pareto chart of probable causes

Create a Corrective Action Plan (CAP)

Once the root cause has been identified, solution options are typically fairly easily identified. The teams often simply brainstorm some corrective actions, and then cumulatively vote again on the one or two things they would like to address in the upcoming period, and the steps they would take to address the item. A Corrective action plan has three elements:

  • Corrective – A different course of action
  • Action – Active steps that can be realistically accomplished
  • Plan – Organize the steps so they can be purposeful, accountable, and measurable

Each activity in the corrective action plan becomes a sticky note that constitutes a program improvement backlog item. During the next days planning session, the Release Train Engineer takes care to assure that the relevant improvement stories are loaded onto the sprint plans, thus assuring that action will be taken, and resources allocated, as with any other backlog item.

In this way, program-level problem solving is routine and systematic, and team members and program stakeholders can be assured that this program is solidly on its journey of continuous improvement.

Inspect & Adapt Template Download

The following Inspect & Adapt  workshop template can be used by any facilitator to help drive effective results from an I&A workshop. It includes workshop exercises, and timings for a 3 hour I&A, normally held at the end of each PSI.

Learn More

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.

[2] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.

[3] Derby, Esther and Larsen, Diana. Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf, 2009.

Last update: 9 May, 2013

© 2010-2013 Leffingwell, LLC. All rights reserved.