Kaizen is about changing the way things are. If you assume that things are all right the way they are, you can’t do kaizen. So change something!

—Taiichi Ohno

Inspect and Adapt

Inspect & Adapt: Overview

The Inspect and Adapt (I&A) is a significant event held at the end of each PI, where the current state of the Solution is demonstrated and evaluated. Teams then reflect and identify improvement backlog items via a structured problem-solving workshop.

The Agile Manifesto emphasizes the importance of continuous improvement through the following principle: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

In addition, SAFe includes ‘relentless improvement’ as one of the four SAFe Core Values as well as a dimension of the Continuous Learning Culture core competency. While opportunities to improve can and should occur continuously throughout the PI (e.g., Iteration Retrospectives), applying some structure, cadence, and synchronization helps ensure that there is also time set aside to identify improvements across multiple teams and Agile Release Trains.

Details

All ART stakeholders participate along with the Agile Teams in the I&A event. The result is a set of improvement backlog items that go into the ART Backlog for the next PI Planning event. In this way, every ART improves every PI. A similar I&A event is held by Solution Trains.

The I&A event consists of three parts:

  1. PI System Demo
  2. Quantitative and qualitative measurement
  3. Retrospective and problem-solving workshop

Participants in the I&A should be, wherever possible, all the people involved in building the solution. For an ART, this includes:

Additionally, Solution Train stakeholders may also attend this event.

PI System Demo

The PI System Demo is the first part of the I&A, and it’s a little different from the regular system demos after every iteration. This demo shows all the Features the ART has developed during the PI. Typically the audience is broader; for example, Customers or Portfolio representatives are more likely to attend this demo. Therefore, the PI system demo tends to be a little more formal, and extra preparation and setup are usually required. But like any other system demo, it should be timeboxed to an hour or less, with the level of abstraction high enough to keep stakeholders actively engaged and providing feedback.

Before or as part of the PI system demo, Business Owners collaborate with each Agile Team to score the actual business value achieved for each of their Team PI Objectives, as illustrated in Figure 1.

The achievement score is calculated by separately totaling the business value for the plan and actual columns. The uncommitted objectives are not included in the total plan. However, they are part of the total actual. Then divide the actual total by the planned total to calculate the achievement score illustrated in Figure 1.

Figure 1. Scoring actual business value for each team
Figure 1. Scoring actual business value for each team

Quantitative and Qualitative Measurement

In the second part of the I&A event, teams collectively review any quantitative and qualitative metrics they have agreed to collect, then discuss the data and trends. In preparation for this, the RTE and the Solution Train Engineer are often responsible for gathering the information, analyzing it to identify potential issues, and facilitating the presentation of the findings to the ART.

Each team’s planned vs. actual business value is rolled up to create the ART predictability measure, as shown in Figure 2.

Figure 2. ART predictability measure is rolled up from each team’s planned vs. actual business value
Figure 2. ART predictability measure is rolled up from each team’s planned vs. actual business value

Reliable trains should operate in the 80–100 percent range; this allows the business and its external stakeholders to plan effectively. (Note: Uncommitted objectives are excluded from the planned commitment. However, they are included in the actual business value achievement, as can also be seen in Figure 1.)

Retrospective

The teams then run a brief (30 minutes or less) retrospective to identify a few significant issues they would like to address during the problem-solving workshop. There is no one way to do this; several different Agile retrospective formats can be used [3].

Based on the retrospective and the nature of the problems identified, the facilitator helps the group decide which issues they want to tackle. Each team may work on a problem, or, more typically, new groups are formed from individuals across different teams who wish to work on the same issue. This self-selection helps provide cross-functional and differing views of the problem and brings together those impacted and those best motivated to address the issue.

Key ART stakeholders—including Business Owners, customers, and management—join the retrospective and problem-solving workshop teams. The Business Owners can often unblock the impediments outside the team’s control.

Problem-Solving Workshop

The ART holds a structured, root-cause problem-solving workshop to address systemic problems. Root cause analysis provides a set of problem-solving tools used to identify the actual causes of a problem rather than just fixing the symptoms. The RTE typically facilitates the session in a timebox of two hours or less.

Figure 3 illustrates the steps in the problem-solving workshop.

Figure 3. Problem-solving workshop format
Figure 3. Problem-solving workshop format

The following sections describe each step of the process.

Agree on the Problem(s) to Solve

American inventor Charles Kettering is credited with saying that “a problem well stated is a problem half solved.” At this point, the teams have self-selected the problem they want to address. But do they agree on the details of the problem, or is it more likely that they have differing perspectives? To this end, the teams should spend a few minutes clearly stating the problem, highlighting the ‘what,’ ‘where,’ ‘when,’ and ‘impact’ as concisely as possible. Figure 4 illustrates a well-written problem statement.

Figure 4. Example problem statement
Figure 4. Example problem statement

Perform Root Cause Analysis

Effective problem-solving tools include the fishbone diagram and the ‘5 Whys.’ Also known as an Ishikawa Diagram, a fishbone diagram is a visual tool to explore the causes of specific events or sources of variation in a process. Figure 5 illustrates the fishbone diagram with a summary of the previous problem statement written at the head of the ‘fish.’

Figure 5. Fishbone diagram with primary sources identified
Figure 5. Fishbone diagram with primary sources identified

For our problem-solving workshop, the main bones often start with the default categories of people, processes, tools, program, and environment. However, these categories should be adapted as appropriate.

Team members then brainstorm causes that they think contribute to solving the problem and group them into these categories. Once a potential cause is identified, its root cause is explored with the 5 Whys technique. By asking ‘why’ five times, the cause of the previous cause is uncovered and added to the diagram. The process stops once a suitable root cause has been identified, and the same process is then applied to the next cause.

Identify the Biggest Root Cause

Pareto Analysis, also known as the 80/20 rule, is used to narrow down the number of actions that produce the most significant overall effect. It uses the principle that 20 percent of the causes are responsible for 80 percent of the problem. It’s beneficial when many possible courses of action compete for attention, which is almost always the case with complex, systemic issues.

Once all the possible causes-of-causes are identified, team members then cumulatively vote on the item they think is the most significant factor contributing to the original problem. They can do this by dot voting. For example, each person gets five votes to choose one or more causes they think are most problematic. The team then summarizes the votes in a Pareto chart, such as the example in Figure 6, which illustrates their collective consensus on the most significant root cause.

Figure 6. Pareto chart of probable causes
Figure 6. Pareto chart of probable causes

Restate the New Problem

The next step is to pick the cause with the most votes and restate it clearly as a problem. Restating it should take only a few minutes, as the teams clearly understand the root cause.

Brainstorm Solutions

At this point, the restated problem will start to imply some potential solutions. The team brainstorms as many possible corrective actions as possible within a fixed timebox (about 15–30 minutes). The rules of brainstorming apply here:

  • Generate as many ideas as possible
  • Do not allow criticism or debate
  • Let the imagination soar
  • Explore and combine ideas

Create Improvement Backlog Items

The team then cumulatively votes on up to three most viable solutions. These potential solutions are written as improvement stories and features, planned in the following PI Planning event. During that event, the RTE helps ensure that the relevant work needed to deliver the identified improvements is planned. This approach closes the loop, thus ensuring that action will be taken and that people and resources are dedicated as necessary to improve the current state.

Following this practice, problem-solving becomes routine and systematic, and team members and ART stakeholders can ensure that the train is solidly on its journey of relentless improvement.

Inspect and Adapt for Solution Trains

The above describes a rigorous approach to problem-solving in the context of a single ART. If the ART is part of a Solution Train, the I&A event will often include key stakeholders from the Solution Train. In larger value streams, however, an additional Solution Train I&A event may be required, following the same format.

Due to the number of people in a Solution Train, attendees at the large solution I&A event cannot include everyone, so stakeholders are selected that are best suited to address the problems. This subset of people consists of the Solution Train’s primary stakeholders and representatives from the various ARTs and Suppliers.

 


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 Diana Larsen. Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf, 2009.

 

Last update: 22 January 2023