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

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

One statement from the Agile Manifesto summarizes how important the philosophy of continuous improvement is to the SAFe Lean-Agile approach: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

SAFe emphasizes the importance of this philosophy by taking it a step further and including relentless improvement as one of the four pillars of the SAFe House of Lean. While opportunities to improve can and should occur continuously (e.g., Iteration Retrospectives), applying some structure, cadence, and synchronization helps ensure that there is also time set aside to consider what can be done better across multiple teams and Agile Release Trains.


All program stakeholders participate with the Agile Teams in the I&A event. The result is a set of improvement backlog items that go to the Program Backlog for the next PI Planning event. In this way, every Agile Release Train (ART) improves every PI. For large solutions, a similar I&A even is held by the Solution Train.

The I&A event consists of three parts:

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

Participants in the program I&A should be, wherever possible, all the people involved in building the system. These include for an ART:

Additionally, Solution Train stakeholders may attend this workshop.

PI System Demo

The PI System Demo is the first part of the I&A, and it’s a little different from the bi-weekly ones that precede it, in that it is intended to show all the Features that the ART has developed over the course of the PI. Typically the audience is broader, for example, additional Customer representatives or Portfolio representatives may choose to attend this demo. Therefore, the PI system demo tends to be a little more formal, and some extra preparation and staging 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.

During the PI system demo, Business Owners, customers, and other vital stakeholders collaborate with each Agile team to rate their actual business value achieved.

Figure 1. Business Owners collaborate with each team to rate their PI objectives during the PI system demo

Quantitative Measurement

In the second part of the event, teams review any quantitative 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.

One primary measurement is the program predictability measure. Each team’s planned vs. actual business value is rolled up to the Program-level in the program predictability measure, as shown in Figure 2.

Figure 2. Program 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 outside stakeholders to plan effectively. (Note: Stretch objectives don’t count toward the commitment but do count toward the actual score, as can also be seen in Figure 1.)


The teams then run a brief (30 minutes or less) retrospective, the goal of which is to identify whatever issues they would like to address. There is no one way to do this; several different Agile retrospective formats can be used [3]. The objective of the retrospective is to identify a few significant problems that the teams can potentially address.

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 then has a choice of resolving Team Level problems or, more typically, selecting a program-level problem and joining others who wish to work on the same issue. This self-selection helps provide cross-functional and differing views of the problem, and it seeds the problem-solving workshop with those who are most likely to be impacted and those who are best motivated to address the issue.

Key ART stakeholders—including Business Owners, customers, and management—join the teams in the retro and problem-solving workshop that follow. Often the Business Owners, and they alone can unblock the impediments that exist outside the team’s control.

Problem-Solving Workshop

For program-level problems, a structured, root-cause problem-solving workshop is held by the ART. Root cause analysis provides a set of problem-solving tools used to identify the actual causes of a problem, rather than just addressing the symptoms. The session is typically facilitated by the RTE, or another facilitator, in a timebox of two hours or less.

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

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 the statement 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 what the problem is, or is it more likely that they have differing perspectives? To this end, the teams should spend a few minutes stating the problem, thinking about the what, where, when, and impact as succinctly as they can. Figure 4 illustrates a Baja Ride systems engineering example.

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 used to explore the causes of specific events or sources of variation in a process. Figure 5 illustrates the fishbone diagram with the problem statement written at the head of the ‘fish.’

Figure 5. Fishbone diagram with major sources identified

For our problem-solving workshop, we preload the main bones with the categories people, process, tools, program, and environment. Causes are identified and then grouped into categories as bones off the main bone. However, these may be adapted as appropriate.

Team members then brainstorm factors that they think contribute to the problem to be solved. Once a root cause is identified, its 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 technique 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 especially useful when many possible courses of action are competing for attention, which is almost always the case with complex, systemic issues.

Once all the possible causes-of-causes have been identified, team members then cumulatively vote on the item they think is the most significant factor causing the end problem. They can do this by placing stars (five stars are allocated to each group member, which can be spread among one or more items as they see fit) on the 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

Restate the New Problem

The next step is to pick the largest cause from the list and restate it clearly as a problem. This should take only a few minutes or so, as the teams are very close to the root cause now.

Brainstorm Solutions

At this point, the root cause will start to imply some potential solutions. The working group brainstorms as many possible corrective actions as they can think 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 likely solutions. These will serve as improvement stories and features to be fed directly into the PI planning session that follows. During that session, the RTE helps ensure that the relevant improvement stories are loaded onto the iteration plans, thus ensuring that action will be taken and resources allocated, as with any other backlog item. This closes the loop on the retrospective and ensures that people and resources are dedicated as necessary to improve the current state.

In this way, problem-solving is routine and systematic at both the program and large solution levels, and team members, program stakeholders, and value stream stakeholders can be assured that the value stream is solidly on its journey of relentless improvement.

Inspect and Adapt at the Large Solution Level

The above describes a rigorous approach to problem-solving in the context of a single program. It often includes key stakeholders from the large solution level, and that is the recommended path to facilitate solution development. In larger value streams, however, an additional large solution level I&A workshop may be required, following the same format.

Due to the number of people in a Solution Train, attendees at large solution I&A workshop cannot include everyone, so stakeholders are selected that are best suited to address that context. This includes the primary stakeholders of the large solution level, as well as 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: 2 October 2018