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!
Inspect and Adapt Abstract
The philosophy of continuous improvement is integral to Agile (” … at regular intervals, the team reflects on how to become more effective … ” Agile Manifesto), Lean Thinking (kaizen), and SAFe. SAFe emphasizes the criticality of this philosophy by embodying relentless improvement as one of the four pillars of SAFe’s House of Lean. Opportunities for relentless improvement occur continuously throughout development. However, applying cadence and synchronization to this philosophy helps ensure that there is dedicated time to spend reasoning about “what we could do better.” The two primary, programmatic opportunities are the team retrospective and this, the Inspect and Adapt workshop.
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 stories 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 Value Stream Level.
The main mechanism in SAFe for achieving relentless improvement, one of the pillars of SAFe’s Lean-Agile Mindset, is the Inspect and Adapt (I&A) workshop. The I&A workshop is held at the end of each Program Increment, to reflect on the execution and results of the previous PI and build improvement backlog items for the next PI. It can be held at both the Program Level and the Value Stream Level. This article focuses primarily on the program event, as those who build the system are those best suited to change the process by which they do so.
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 Management, Business Owners, and others on the train. Value Stream stakeholders may also attend this workshop.
The I&A workshop consists of three parts:
- PI System Demo
- Quantitative measurement
- Retrospective and problem-solving workshop
PI System Demo
A System Demo is the first part of the workshop. This particular system demo is 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.
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 Value Stream 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.)
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 . 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.
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.
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.
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.”
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.
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 take a minute or so, as the teams are very close the root cause now.
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 VS 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 Value Stream Level
The above describes a rigorous approach to problem-solving in the context of the program. It often includes key stakeholders from the value stream level, and that is the recommended path to facilitate Solution development. In larger value streams, however, an additional 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 value stream level, as well as representatives from the various ARTs and Suppliers.
Learn More Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.  Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.  Derby, Esther and Diana Larsen. Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf, 2009.
Last update: 21 April 2016