SAFe® in a Nutshell – The Inspect & Adapt (I&A) Workshop

In our last installment, we explored the activities involved in the execution of a Program Increment (PI). Now, let’s take a look at what happens in a SAFe Inspect & Adapt (I&A) Workshop and how it influences the next PI planning session.

 

What is the SAFe Inspect & Adapt Workshop?

The importance of the Inspect & Adapt ceremony in SAFe™ cannot be understated. It enables every Agile Release Train (ART) to embody “relentless improvement” as referenced in the SAFe House of Lean, maintain its overall health and deliver ever-increasing business value.

The Inspect & Adapt Workshop is essentially the release train equivalent of the team’s Sprint Review and Sprint Retrospective. Both ceremonies at the team level are encapsulated into the single Inspect & Adapt workshop for the ART.

The I&A, which occurs at the end of each PI during the Innovation and Planning (IP) Sprint, is a key event for teams to highlight what was accomplished and receive feedback that will help inform the next PI.

The entire train is present at this Inspect & Adapt Workshop, including the Business Owner(s), other key stakeholders, and potentially even customer representatives.

 

What are the Three Parts of a SAFe I&A?

PI System Demo

The PI System Demo is the final installment and is focused on demonstrating what was accomplished in the entire PI. Since we’re in the IP sprint (and this is not considered a development sprint because we’re no longer planning stories) this is the final version of the System Demo (which we learned in PI execution occurs each sprint in the PI after the first to illustrate increment integration of the team’s sprint output) where the team will show all the end-to-end functionality that was achieved throughout the PI. Team representatives may conduct the demo, or the product management team themselves can take ownership.

An objective-focused PI demo is most effective; this demo should illustrate the business value delivered by focusing on those objectives, and tell the story of how those objectives are now implemented within the system.

Overall, the PI System Demo should:

• Tell a story that would be meaningful to the business owners and the business stakeholders in the room. Ideally, the teams would have discussed what “story” the business owners would like to see at this demo during the PI planning session so that the teams could be planning for what to show throughout the PI.
• Allow some time for feedback after the demo. Feedback from stakeholders can include:
• Did this meet expectations?
• Did you see anything that you didn’t expect?
• Or, did you get more than you expected?

Quantitative and Qualitative Metrics

This second part of the I&A is a review of metrics on what was accomplished.

• PI Predictability Measure – This is the key metric we look at during this portion of the I&A. This metric measure the planned business value versus the actual business value that the team has accomplished against their objectives.
• Business owners will collaborate with the team to provide a score on the actual business value that was delivered, in comparison to what the team committed to during the PI Planning session. The score should be based on whether the team accomplished their planned objectives- regardless of whether or not that objective still has the same business value in the current market. It should really be a measure of to what extent the team delivered to the business owners expectation of what they said they would. The graphic below illustrates how the PI predictability measure is calculated and shown.
• Note: During PI Planning, the team may have come up with stretch objectives, in addition to their committed objectives. Stretch objectives do not count as part of the plan, so it is possible for a team or the whole train to achieve over 100% of business value delivered, in the case that they met some or all of their stretch objectives in addition to their committed objectives.

(Fig. 1 – Team PI Objectives)

(Fig. 2 – Team PI Performance Reports and Program Predictability Measure)
• Other measures the team may explore include:
• Velocity that the train achieved
• The number of features and number of stories completed
• Defects found, etc.

The goal here is to show a trend of key metrics to serve as discussion points for what might be driving a positive or negative trend to the metric.

Problem Solving Workshop

Essentially, this is the equivalent of the team-level retrospective. Now that the teams have received feedback and everyone can see what was delivered in the current PI, it’s important to relentlessly improve as a train and discuss challenges and impediments. During this Problem Solving Workshop, we aim to understand how we can systematically improve and mitigate those impediments better going forward.

Download this webinar to learn more about how to break through the barrier of virtual impediments and successfully run a virtual Problem Solving Workshop.

The problem solving workshop should focus on large issues that have affected multiple teams, for example:

• Environmental issues that have impacted the teams
• Teams colliding with each other
• New pieces of technology that failed

The workshop starts with the RTE presenting candidate problems for the teams to discuss. This could have been collected throughout the PI during the Scrum of Scrums as the teams were highlighting impediments that continued to be an impact. Alternatively, the RTE could also facilitate a quick brainstorm at the start of the event to elicit other nominations and then do a quick dot vote to see which ones bubble to the top.

Afterward, once the RTE has identified a small number of candidate problems to discuss, the teams on the ART should self-organize into teams around the problems to discuss. These teams generally do not align to the actual teams on the train (and it’s better if they do not). Ultimately, people should self-select which problem they want to be part of based on their context with that problem and where they might best contribute. You should still strive to have scrum-sized teams for each problem. Also, you might have to form multiple teams to discuss the same problem as needed. This way, you’ll get multiple perspectives on potential root causes and actions that could be taken to address.

Once the teams have been formed around the various problems, we head into a six step process:

1. Define a well-formed problem statement
2. Perform a Root Cause Analysis

Teams will use a fishbone diagram, otherwise known as an Ishikawa diagram, and use the 5 Whys technique to reflect on why each problem occurred

3. Identify the most significant root cause

Team members will use a Pareto Analysis to try to find 20% of the root causes that caused 80% of the problem. Team members dot vote on all the root causes that came up to identify the most significant root cause.

4. Restate that original problem statement in terms of the root cause

The problem is no longer the original problem statement. Rather, it’s the root cause that actually led to the problem.

5. Brainstorm potential solutions

Team members will brainstorm potential solutions to the restated problem in step 4 to fix the problem moving forward..

6. Prioritize, dot vote, and create backlog items to track solutions and improvements moving forward

The key is to actually prioritize these items on the backlog and proactively plan into the next PI to ensure that progress is being made and the team continues to relentlessly improve. If you don’t take action to resolve these problems, future workshops will be impacted since teams may not believe that any action will be taken.

(Fig. 3 – Steps in the Problem Solving Workshop)

What Happens Next?

As we head into PI Planning for the next PI, with our business value score, an overview on metrics, and identified improvement items at our disposal, the teams can incorporate the feedback from this I&A into the next PI, both in terms of the functionality of the system, as well as those improvement areas that we can proactively plan.

Now, with the completion of the I&A Workshop, that concludes the part of our series involving the planning, executing, and relentless improving of an Agile Release Train. In our next installment, we’ll discuss the Large Solution Level of SAFe. This is an optional level that is only used by larger systems and organizations that require multiple ARTs collaborating and aligning to build and deploy some of the most complex systems in the world. All you “rocket scientists” out there might want to tune in for this one!