Inspect & Adapt: SAFe's Formal Improvement Event

The mental model

Think of the Inspect & Adapt (I&A) event as a scheduled pit stop for the entire race team, not just a single driver. It's a formal, structured event in the Scaled Agile Framework (SAFe) where an entire Agile Release Train (ART) pauses to reflect on the last Program Increment (PI). The goal is to analyze what actually happened, identify systemic problems, and commit to concrete improvements for the next PI. It makes the SAFe core value of 'relentless improvement' a tangible practice.

How it works

The I&A is a cadence-based event with three distinct parts. First is the PI System Demo, where the ART demonstrates the current, integrated state of the solution to all stakeholders. This shows the real progress made. Second is a quantitative and qualitative measurement review, where the ART analyzes metrics and progress against the PI's goals. Third is a retrospective and problem-solving workshop. Here, teams reflect on the PI, identify major impediments, and use a structured approach to find root causes and create actionable improvement backlog items.

When to use it

The I&A event is a mandatory part of the SAFe framework, held at the end of every Program Increment. It is specifically designed for environments where multiple Agile teams are working together as an Agile Release Train. Use it to synchronize reflection and improvement across the entire system, ensuring that problems between teams or in the overall process are addressed. It's the primary mechanism for making the whole ART more effective over time.

When not to use it

This large-scale, multi-part event is overkill for a single, independent Agile team. A standard team-level retrospective is sufficient in that context. The I&A's significant time investment is only justified when you need to coordinate improvement across a large group of teams and stakeholders. Applying the full ceremony without the context of an ART and PI would be inefficient and miss the point of systemic, cross-team problem-solving.

One canonical example

An ART consistently misses its PI objectives. During the I&A workshop's problem-solving portion, multiple teams identify late-discovered dependencies as a recurring issue. The group traces this to a lack of a shared understanding of cross-team work during planning. They create an improvement backlog item: "Implement a formal dependency mapping session during PI Planning." This item is then prioritized for the ART's backlog, ensuring the system itself is improved for the next PI.