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 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 pillars of the SAFe House of Lean as well as a dimension of the Continuous Learning Culture core competency. While opportunities to improve can and should occur continuously throughout the Program Increment (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 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 event is held by the Solution Train.
The I&A event consists of three parts:
- PI System Demo
- Quantitative and qualitative measurement
- Retrospective and problem-solving workshop
Participants in the I&A should be, wherever possible, all the people involved in building the solution. These include for an ART:
- The Agile teams
- Release Train Engineer (RTE)
- System and Solution Architects/Engineering
- Product Management, Business Owners, and others on the train
Additionally, Solution Train stakeholders may 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 that happen after every iteration, 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, customers or Portfolio representatives are more likely 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.
Prior to, 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.
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.
One primary metric is the program predictability measure. Each team’s planned vs. actual business value is rolled up to create the program predictability measure, as shown in Figure 2.
Reliable trains should operate in the 80–100 percent range; this allows the business and its external stakeholders to plan effectively. (Note: Uncommitted objectives don’t count toward the commitment but do count toward 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, the goal of which is 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 it brings together those who are 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 retrospective and problem-solving workshop. Often it is the Business Owners alone who can unblock the impediments that exist outside the team’s control.
Problem-Solving Workshop
For addressing systemic 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, in a timebox of two hours or less.
Figure 3 illustrates the steps in the problem-solving workshop.
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 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 succinctly as they can. Figure 4 illustrates a well-written 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 a summary of the previous problem statement written at the head of the ‘fish.’
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 causes that they think contribute to the problem to be solved and group them into these categories. Once a cause is identified, its root cause is explored with the 5 Whys technique. By simply asking ‘why’ multiple 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 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 contributing to the original problem. They can do this by dot voting (five votes are allocated to each person, 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.
Restate the New Problem
The next step is to pick the cause with the most votes and restate it clearly as a problem. This should take only a few minutes or so, as the teams have a good understanding of this root cause by now.
Brainstorm Solutions
At this point, the restated problem will start to imply some potential solutions. The team brainstorms as many possible corrective actions as they can think of 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 are rephrased as improvement stories and features to be fed directly into the PI Planning event that follows. During that event, the RTE helps ensure that the relevant work needed to deliver the identified improvements is planned. This closes the loop, thus ensuring that action will be taken and that people and resources are dedicated as necessary to improve the current state.
In this way, problem-solving becomes routine and systematic, and team members and ART stakeholders can be assured that the train 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 ART. If the ART is part of a Solution Train the I&A event will often include key stakeholders from the Large Solution level. In larger value streams, however, an additional large solution level 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 faced. This includes the primary stakeholders of the Solution Train, 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: 10 February 2021
