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!
The Inspect and Adapt (I&A) event is a crucial gathering that takes place at the end of each Program Increment (PI). During this event, the current state of the Solution is demonstrated and evaluated by the train. Teams then engage in reflection and identify areas for improvement through a structured and problem-solving workshop.
Table of Contents
Continuous Improvement in Agile
The Agile Manifesto emphasizes the significance of continuous improvement, stating that teams should regularly reflect on their processes and behaviors to enhance their effectiveness. SAFe (Scaled Agile Framework) also places great importance on continuous improvement, considering it one of the four pillars of the SAFe House of Lean and a core competency of the Continuous Learning Culture.
While opportunities for improvement may arise throughout the Program Increment, applying structure, cadence, and synchronization ensures that dedicated time is set aside to identify improvements across multiple teams and Agile Release Trains.
All stakeholders involved in the Agile Release Train (ART) participate in the I&A event. The outcome of this event is a set of improvement backlog items that are incorporated into the Program Backlog for the next PI Planning event. Consequently, every ART sees improvement with each PI. For large-scale solutions, a similar I&A event is held by the Solution Train.
Components of the I&A Event
The I&A event comprises three key parts:
- PI System Demo
- Quantitative and Qualitative Measurement
- Retrospective and Problem-Solving Workshop
PI System Demo
The PI System Demo kicks off the I&A event. It differs slightly from regular system demos conducted after each iteration. Its purpose is to showcase all the Features that the ART has developed over the course of the PI. The audience for this demo is usually broader and may include customers or representatives from the portfolio. As a result, the PI system demo tends to be a little more formal, requiring extra preparation and staging. Nevertheless, like any other system demo, it should be timeboxed to an hour or less and keep stakeholders actively engaged.
During or before the PI system demo, Business Owners collaborate with each Agile team to assess the actual business value achieved for each of their Team PI Objectives.
Figure 1: Business Owners collaborate with each team to rate their team PI objectives during the PI system demo
Quantitative and Qualitative Measurement
In the second part of the I&A event, teams collectively review the quantitative and qualitative metrics they agreed to collect. They discuss the data and trends, and in preparation for this, the RTE (Release Train Engineer) and the Solution Train Engineer analyze the information to identify potential issues. They then facilitate the presentation of the findings to the ART.
One primary metric examined is the program predictability measure, which rolls up each team’s planned versus actual business value. The program predictability measure ensures that reliable trains operate between 80-100 percent, enabling effective planning for the business and its external stakeholders. Uncommitted objectives don’t count towards the commitment but contribute to the actual business value achievement.
Following the quantitative and qualitative measurement, the teams engage in a brief retrospective, lasting no more than 30 minutes. The goal is to identify significant issues that will be addressed during the problem-solving workshop. There are various Agile retrospective formats that can be used for this purpose.
Based on the retrospective and the problems identified, the facilitator helps the group decide which issues they want to tackle. Sometimes, teams work on a problem individually, but more commonly, groups are formed with members from different teams who wish to address the same issue. This approach ensures a cross-functional and diverse perspective, involving those impacted and those best motivated to resolve the problem.
Key ART stakeholders, including Business Owners, customers, and management, participate in the retrospective and problem-solving workshop. Business Owners often play a crucial role in unblocking impediments that exist outside the team’s control.
To address systemic problems effectively, the ART conducts a structured, root-cause problem-solving workshop. This workshop is facilitated by the RTE and typically lasts no more than two hours.
The problem-solving workshop follows several steps, as illustrated in the diagram below:
Figure 3: Problem-solving workshop format
- Agree on the Problem(s) to Solve: The teams spend a few minutes clearly stating the problem, including the “what,” “where,” “when,” and “impact” of the problem.
- Perform Root Cause Analysis: The teams utilize problem-solving tools like fishbone diagrams and the “5 Whys” technique to explore the causes of the problem. They identify the root cause by asking “why” multiple times.
- Identify the Biggest Root Cause: The team employs Pareto Analysis, the 80/20 rule, to determine the most significant factor contributing to the problem. They use dot voting to reach a consensus on the most problematic root cause.
- Restate the New Problem: The cause with the most votes is restated clearly as a problem.
- Brainstorm Solutions: The teams generate as many potential corrective actions as possible within a fixed timebox.
- Create Improvement Backlog Items: The team votes on the top three solutions and converts them into improvement stories and features to be included in the PI Planning event. During this event, the RTE ensures that the necessary work to implement the identified improvements is planned.
This approach ensures that problem-solving becomes routine and systematic. It also guarantees that the necessary actions are taken and resources dedicated to improving the current state.
Inspect and Adapt at the Large Solution Level
The aforementioned approach describes the problem-solving process within a single ART. However, if the ART is part of a larger Solution Train, the I&A event may include key stakeholders from the Large Solution level as well. For more extensive value streams, an additional large solution level I&A event may be required, following the same format.
Due to the number of people involved in a Solution Train, not all stakeholders can attend the large solution I&A event. Those selected to attend are best suited to address the problems faced. This includes primary stakeholders from the Solution Train, representatives from various ARTs, and Suppliers.
If you want to delve deeper into the topic, you can find more information in the following references:
- 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: 10 February 2021