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. 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 SAFe’s 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 by including relentless improvement as one of the four pillars of SAFe’s House of Lean. While opportunities for relentless improvement can and should occur continuously, applying some structure and cadence and synchronization helps ensure that there is also time set aside to consider “what we can do better.” Two primary, programmatic opportunities are the Iteration Retrospective and the Inspect and Adapt (I&A) workshop. Details

The inspect and adapt (I&A) workshop is a significant event held at the end of each Program Increment. I&A is a regular time to reflect, collect data, problem solve, and take action on improvement actions needed to increase the velocity, quality, and reliability of the next PI. All program stakeholders participate in this workshop. The result of the workshop is a set of improvement backlog items that can be added to the backlog for the upcoming PI Planning. In this way, every ART improves every PI. For large solutions, a similar I&A workshop also typically occurs at the Large Solution Level.

Participants in the program I&A workshop should be, wherever possible, all the people involved in building the system. These include the Agile Teams, Release Train Engineer (RTE), System and Solution Architect/Engineering, Product ManagementBusiness Owners, and others on the train. Value Stream stakeholders may also attend this workshop.

The I&A workshop consists of three parts:

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

PI System Demo

The PI System Demo is the first part of the workshop and it’s a little different from the biweekly ones that precede it, in that it is intended to show all the accumulated Features that have accrued over the course of the PI. Also, typically the audience is broader, as, for example, additional Customer representatives may choose to attend this demo. Therefore the demo tends to be a little more formal in nature, and some additional preparation and staging is usually required. But like any other system demo, this one should be timeboxed to an hour or less, with the level of abstraction high enough to keep the important stakeholders engaged and providing feedback.

Quantitative Measurement

In the second part of the workshop, 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 showcase interesting statistics and findings, and facilitating the presentation of the measurements.

One primary measurement is the Program Predictability Measure. During the PI system demo, the Business Owners, Customers, Agile Teams, and other key stakeholders collaboratively rate the actual business value achieved for each team’s PI Objectives, as shown in Figure 1. Reliable trains should generally operate in the 80% – 100% range; this allows the business and its outside stakeholders to plan effectively. (Note: Stretch objectives don’t count in the commitment but do count in the actual score, as can also be seen in Figure 1.)

Figure 1. Team PI Performance Report

Retrospective and Problem-Solving Workshop


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; a number of Agile retrospective formats can be used [3]. The objective of the selected format is to identify a small number of significant problems that the teams can potentially address.

Based on attendance at the retrospective, and the nature of the problems identified, the facilitator helps the group decide which ones they want to tackle.

They then have 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 team 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 this retro. Often they, and they alone, can unblock the impediments that exist outside the team’s control.

Problem-Solving Workshop

For the larger, systematic program-level problems, a structured, root cause analysis-based, problem-solving workshop format can be applied. Root cause analysis is a set of problem-solving tools used to identify the root causes of a problem, rather than simply addressing the symptoms. The session is typically facilitated by the RTE, or other facilitator, in a timebox of two hours or less.

The steps in the workshop are depicted in Figure 2 below. Each is described in the following sections.

Figure 2. Problem-solving workshop format

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 work on. But do they really 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 3 illustrates a Baja Ride systems engineering example.

Figure 3. Example problem statement

Perform Root Cause Analysis

We recommend the use of traditional and effective problem-solving tools including Fishbone Diagrams and the Five Whys. 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 grouped into major categories as bones off the main bone. For our 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 used to narrow 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 problem. 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 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 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

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 only a few minutes or so, as the teams are very close 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 of in a 15 – 30 minute session. The rules of brainstorming apply here:

  • Generate as many ideas as possible
  • Do not allow criticism or debate
  • Let the imagination soar
  • Mutate 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 improving 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 the 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 inspect and adapt workshop may be required, following the same format. Attendees at that workshop cannot include all stakeholders, 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: 17 June, 2017