Inspect and Adapt in SAFe: The Complete Guide to I&A Events

Inspect and Adapt (I&A) improvement items vanish between PIs when the three-part feedback chain breaks. How the demo, measurement, and workshop connect.

Most Agile Release Trains run Inspect and Adapt (I&A) at the end of every Program Increment (PI) and wonder why nothing changes. The demo gets applause, the metrics get reviewed, the workshop produces a list; and by the next PI Planning, those improvement items have quietly disappeared. It’s not effort that’s missing. It’s that I&A is being run as three disconnected activities instead of a single, integrated feedback system.

What Is Inspect and Adapt in SAFe?

I&A is the final event of every PI in the Scaled Agile Framework (SAFe), structured as a three-part ceremony where the Agile Release Train (ART) demonstrates integrated work, measures actual versus planned value delivery, and applies structured root-cause analysis to the most pressing systemic impediments (Scaled Agile Framework. Unlike team-level Iteration Retrospectives, which focus on team dynamics and sprint mechanics, I&A operates at ART scope; addressing problems that no single team can solve alone.

The distinction matters enormously in practice. Teams using I&A as a glorified retrospective consistently report the same impediments PI after PI. Teams who understand I&A as the ART’s primary learning mechanism, where quantitative performance data, stakeholder feedback, and structured problem-solving converge, use it to systematically dismantle the organizational obstacles that constrain delivery.

I&A Within the PI Cadence Timeline

I&A occurs in the final week of every Program Increment, after all iteration work is complete and before the next PI Planning event. In a standard 10-to-12-week PI, this positions I&A as the cadence pivot: the point where the ART closes the current increment and begins orienting toward the next one.

The sequence matters. I&A follows the last iteration’s Iteration Review and Retrospective, which means team-level learnings have already been captured. What remains are the systemic issues, integration failures, cross-team dependencies, architectural constraints, and organizational impediments, that exist above the team level. These are I&A’s domain.

The event typically runs three to four hours for a single ART, though duration scales with ART size and complexity. Facilitation falls to the Release Train Engineer (RTE), who is responsible for orchestrating all three parts, maintaining timeboxes, and ensuring the event produces actionable improvement items rather than venting sessions.

The Deming Roots of Inspect and Adapt

I&A is not an original SAFe invention. It is the ART-level operationalization of W. Edwards Deming’s Plan-Do-Check-Act (PDCA) cycle, applied within the PI cadence. PI Planning is the Plan phase. The PI execution iterations are the Do phase. I&A is the Check-Act phase; where the ART checks what was accomplished against what was planned, then acts to improve the system that produced those results.

Deming’s fundamental insight was that improvement requires a closed feedback loop. Systems that plan and execute without structured reflection and adjustment don’t improve; they merely repeat. The PDCA cycle imposes that closed loop. In SAFe, I&A is the mechanism that closes the loop at ART level, PI after PI, building organizational learning into the cadence rather than leaving it to chance.

What distinguishes I&A from generic retrospectives is this grounding in measurement. Deming insisted that improvement must be evidence-based: “In God we trust; all others bring data.” I&A operationalizes this by requiring quantitative measurement, specifically the PI Predictability Measure, before any problem-solving begins. Without data, improvement discussions are opinion contests. With data, they become scientific inquiries into what the system actually produced and why.

I&A vs Team Retrospectives; Scope and Purpose

The most common misapplication of I&A is treating it as a scaled-up version of an Iteration Retrospective. The confusion is understandable, both involve reflection and improvement, but the scope difference is fundamental.

Iteration Retrospectives are team-level events focused on team dynamics, process mechanics, and iteration-specific issues. They’re designed to improve how a team works together within their iteration cadence. The improvements they generate are team-owned and team-executable.

I&A operates at ART level and addresses a categorically different class of problems: systemic impediments that span teams, organizational constraints that require management action, architectural issues that affect the integrated solution, and cross-team coordination failures. These problems cannot be resolved by any single team acting alone; they require ART-level visibility and organizational authority to address.

A team retrospective might surface that the team’s definition of done is unclear. I&A surfaces that integration failures between teams are systemic because there’s no continuous integration environment that spans the ART. The first problem is team-solvable. The second requires architectural investment and cross-team coordination that only ART-level visibility can reveal and only organizational leadership can authorize.

How Is I&A Structured? The Three-Part Feedback System

I&A is structured as three sequential parts that form an integrated feedback system: the PI System Demo, Quantitative and Qualitative Measurement, and the Problem-Solving Workshop (agility-at-scale.com. Each part produces outputs that feed into the next, creating the causal chain that makes I&A work. Organizations that run the three parts as disconnected agenda items consistently report poor outcomes; because they’ve broken the chain.

The causal logic is precise: the PI System Demo reveals what was built. The Measurement phase reveals whether what was built delivered value. The Problem-Solving Workshop addresses why gaps exist between what was planned and what was delivered. Each question depends on the previous answer. Skip or compress any part, and the chain breaks.

Timebox Allocation for Each I&A Part

For a standard four-hour I&A event, time typically distributes across the three parts as follows:

These are guidelines, not rules. Larger ARTs with more teams need more demo time. ARTs encountering complex systemic problems may need a longer workshop. The Release Train Engineer adjusts timeboxes based on ART context, but should resist the temptation to compress the measurement or workshop phases when time pressure appears: these are the parts most likely to produce genuine improvement.

Information Handoff Between Demo, Measurement, and Workshop

The value of I&A comes from treating the three parts as a single analytical process rather than a structured agenda.

The PI System Demo generates two outputs that flow directly into measurement: a record of what was demonstrated (what functionality was actually completed and integrated) and stakeholder feedback on the quality and value of what was delivered. Business Owners attending the demo begin scoring PI Objectives mentally based on what they observe.

The Measurement phase takes these inputs and quantifies the gap between planned and actual value delivery. The PI Predictability Measure, calculated from Business Owner scores of actual versus planned business value, becomes the primary evidence for problem-solving. Additional flow metrics (cycle time, throughput, velocity trends) provide supporting context.

The Problem-Solving Workshop opens with this measurement data on the table. The team doesn’t start from vague feelings about what went wrong; they start from quantified evidence of the performance gap. This data grounds the problem statement and prevents the workshop from degenerating into opinion-based discussion or blame sessions.

Participant Roles Across the Three Parts

Not every participant attends every part with the same level of engagement.

PI System Demo: Full attendance by all ART members, Business Owners, key stakeholders, and leadership. This is a stakeholder event as much as a team event. Business Owners must be present to score PI Objectives accurately.

Measurement Review: RTE-led review with ART members, Business Owners, and leadership. Finance or portfolio stakeholders may join if PI Predictability data has budget implications.

Problem-Solving Workshop: Core team of ART members facilitated by the RTE, with representatives from management who have authority to commit to systemic changes. Senior leadership may attend but should resist the urge to drive the discussion: the people closest to the work identify problems most accurately.

What Happens During the PI System Demo?

The PI System Demo is a demonstration of the integrated solution across the entire ART, evaluated against PI Objectives rather than feature checklists (PMExpert. The Agile Manifesto’s principle that “working software is the primary measure of progress” applies here in its strongest form; what matters is not what was built but what value was delivered to users. It is not a sequence of team demos stitched together. The critical distinction: individual team demos show what each team built; the PI System Demo shows whether the ART delivered value as a system.

This distinction has profound implications for how the demo is prepared and run. When teams demo individually, each team shows their best work in their best environment. When the ART demos as a system, integration gaps become visible; features that work in isolation but fail in combination, value streams that don’t flow end-to-end, architectural assumptions that don’t hold under integrated conditions.

Demonstrating Value Against PI Objectives

Every PI begins with agreed PI Objectives: the business outcomes the ART committed to deliver. The PI System Demo should demonstrate progress against these objectives, not enumerate features completed.

This is a meaningful shift in how most ARTs approach the demo. Feature-focused demos answer the question “what did we build?” Objective-focused demos answer the question “did we deliver what we committed to deliver, and did it move the business forward?” Business Owners can engage substantively with the second question. They can only applaud politely at the first.

Practical preparation requires identifying, before the demo, which PI Objectives each demonstration segment addresses. The demo facilitator (usually the RTE or a designated lead) should make these connections explicit: “This segment demonstrates Objective 3: enable customers to complete self-service account updates without agent assistance.” Stakeholders can then evaluate whether what they’re seeing actually achieves the objective, not just whether the feature works.

Stakeholder Feedback Collection Techniques

The PI System Demo is also a structured feedback collection event. Business Owners and stakeholders are not passive audiences; they are active participants who contribute the qualitative data that supplements quantitative measurement.

Effective feedback collection methods include:

• Real-time scoring: Business Owners score each PI Objective segment (0-10) immediately after it’s demonstrated, before moving to the next segment. This prevents halo effects from strong later segments distorting scores for weaker earlier ones.
• Written feedback cards: Stakeholders capture specific observations during the demo rather than trying to reconstruct them during the measurement review.
• Structured Q&A: Brief Q&A after each major objective segment, focused on whether the demonstrated functionality meets the stated objective: not general feature requests or scope expansion discussions.

Technical Preparation for the Integrated Demo

The PI System Demo requires an integrated environment: not individual team environments. This preparation challenge is often underestimated. Getting code from multiple teams integrated, deployed to a shared environment, and stable enough for a live demonstration is itself a technical achievement that many ARTs struggle with.

What we’ve found is that ARTs with continuous integration practices in place find demo preparation straightforward. ARTs without continuous integration discover at demo preparation that their components don’t integrate cleanly; and that discovery, while painful, is itself valuable I&A data about an architectural gap that needs addressing.

The RTE should establish a demo preparation checklist and run a technical rehearsal at least one day before I&A. This rehearsal identifies integration failures while there’s still time to address them (or acknowledge them honestly during the demo as learning, rather than hiding them by switching to backup slides).

How Do You Measure PI Performance?

The Quantitative Measurement Review phase of I&A is where SAFe diverges most sharply from Scrum-style retrospectives; and where most ARTs underperform. The PI Predictability Measure is the single most important quantitative signal in SAFe: it calculates the ratio of actual business value delivered to planned business value, expressed as a percentage (Lean Wisdom. Business Value Scoring, the process by which Business Owners assign numeric values to PI Objectives at planning and then re-score at I&A, is the mechanism that makes this measurement possible. This Deming-inspired insistence on quantification is what makes I&A a scientific improvement process rather than a structured conversation.

Taiichi Ohno’s principle applies directly here: “Without standards there can be no kaizen.” The PI Predictability Measure is the standard. Without it, the ART has no baseline to improve against; only feelings about how the PI went.

Calculating PI Predictability Measure

The PI Predictability Measure calculation requires two data points for each PI Objective:

1. Planned Business Value (PBV): The business value Business Owners assigned to each objective during PI Planning, scored 1-10 for committed objectives and 1-3 for stretch objectives.
2. Actual Business Value (ABV): The business value Business Owners assign to each objective during I&A, based on what was actually delivered.

The formula:

PI Predictability = (Sum of ABV / Sum of PBV) × 100%

A predictability rate between 80-100% is generally considered healthy. Consistently below 80% indicates systematic over-commitment or delivery obstacles that need structural attention. Consistently at 100% may indicate under-commitment; teams sandbagging to ensure they always “win” against their objectives.

A worked example: An ART commits to five PI Objectives with planned business values of 10, 8, 9, 7, and 6 (total: 40). Business Owners score actual delivery at 9, 6, 8, 5, and 5 (total: 33). PI Predictability = 33/40 × 100 = 82.5%.

Business Owner Scoring Methodology

The integrity of the PI Predictability Measure depends entirely on honest Business Owner scoring. This is where the measurement phase most commonly breaks down in practice.

Business Owners who feel pressure to protect their teams, or who want to maintain good relationships with team members, tend to inflate scores. Business Owners who are frustrated with delivery failures may deflate scores. Neither produces useful data.

Effective Business Owner scoring requires:

• Objective criteria established at PI Planning: What does full delivery look like? Partial delivery? Business Owners should define what score they would assign for different delivery scenarios before the PI begins.
• Psychological safety for honest scoring: Leaders who create environments where honest assessment is rewarded, not punished, get accurate data. Leaders who create environments where low scores feel like attacks get inflated scores and useless measurement.
• Immediate scoring during the demo: Business Owners score each objective as it’s demonstrated, not collectively at the end. End-of-demo scoring allows the overall impression to color individual objective assessments.

High-performing ARTs treat PI Predictability data as a diagnostic signal rather than a performance grade. A score of 75% isn’t a team failing: it’s a system revealing where planning assumptions were inaccurate, where obstacles weren’t anticipated, or where dependencies weren’t managed effectively. That’s exactly the information the problem-solving workshop needs.

Flow Metrics Review During I&A

Beyond PI Predictability, I&A typically reviews flow metrics that provide additional diagnostic context:

• Velocity trends: Is team velocity stable, improving, or declining across PIs? Declining velocity in the absence of team changes suggests accumulating technical debt.
• Throughput: How many features/stories completed per sprint? Meaningful when compared across PIs with similar scope.
• Cycle time: How long do work items take from start to finish? Increasing cycle time indicates growing impediments to flow.

These metrics don’t replace PI Predictability; they supplement it. PI Predictability tells you whether the ART delivered the value it committed to. Flow metrics reveal the systemic patterns in how work moved through the system.

Synthesizing Qualitative Demo Feedback with Quantitative Data

The final preparation step before the Problem-Solving Workshop is synthesizing the qualitative feedback from the PI System Demo with the quantitative PI Predictability and flow data. The RTE or a designated facilitator should identify where qualitative observations and quantitative data converge.

When Business Owners score an objective low and stakeholder feedback during the demo identified integration failures in that same area, you have a convergent signal: the low score reflects a real delivery gap, not a scoring artifact. That convergence makes a compelling problem statement for the workshop.

When quantitative predictability is high but qualitative feedback is negative (stakeholders got what was planned but not what they needed), you have a different, and often more concerning, signal: the ART is building to specification while missing user value. That’s a planning or objective-setting problem, not a delivery problem.

How Do You Run the Problem-Solving Workshop?

The Problem-Solving Workshop is the most structured and most commonly corrupted part of I&A (Scrum Institute. It follows a six-step sequence developed within SAFe that applies disciplined root-cause analysis (RCA) tools, specifically Kaoru Ishikawa’s fishbone diagram, the Five Whys technique, and Pareto analysis, within a structured timebox. Root Cause Analysis (RCA) is the core analytical discipline: rather than treating symptoms, the workshop systematically traces the chain of causes to find the system-level condition that, if changed, would eliminate the problem. This is not free-form brainstorming. The discipline of the method is what separates I&A from generic retrospectives.

Step-by-Step: The Six-Part Problem-Solving Sequence

Step 1: Agree on the Problem to Solve

The workshop opens by selecting one problem to address. This seems counterintuitive, most ARTs have many problems, but attempting to address multiple problems simultaneously produces shallow solutions for all of them. The RTE uses the measurement data from Phase 2 to facilitate problem selection, typically through dot voting on a curated list of candidate problems derived from PI Predictability gaps and qualitative feedback.

The agreed problem must be stated in terms of outcomes, not solutions: “Our integration failures are causing us to miss PI Objectives” is a problem statement. “We need a CI/CD pipeline” is a solution statement masquerading as a problem.

Step 2: Root-Cause Analysis via Fishbone Diagram

Once the problem is agreed, the team applies Ishikawa’s fishbone (cause-and-effect) diagram to identify root causes systematically. The fishbone structure prevents the common failure mode of jumping from problem to solution without understanding why the problem exists.

The diagram has a “spine” pointing to the problem statement, with “bones” representing major causal categories. For software delivery problems, common categories include: People, Process, Technology, Environment, Management, and Measurement. For each category, participants brainstorm contributing causes: not solutions.

This step typically takes 20-30 minutes and generates a rich picture of contributing factors. What we consistently observe is that the true root cause identified through this analysis is rarely the first answer participants gave when asked “what’s causing this?” Surface causes are visible; root causes require structured inquiry to surface.

Step 3: Identify the Biggest Root Cause via Pareto Analysis

The fishbone diagram typically reveals multiple contributing causes. Pareto analysis, the 80/20 principle that 80% of problems stem from 20% of causes, helps the group identify which root cause, if addressed, would have the greatest impact on the problem.

Participants vote on root causes (dot voting works well), with each person distributing a fixed number of votes across the causes they believe are most significant. The cause receiving the most votes becomes the focus. The Pareto principle suggests that addressing this highest-vote cause will produce the largest improvement in outcomes, even if other causes remain.

Step 4: Restate the Problem as a Solvable Problem Statement

Before brainstorming solutions, the agreed root cause is restated as a solvable problem statement using the format: “How might we [address root cause] so that [improved outcome]?”

This restatement is not bureaucratic: it’s cognitive. “We have poor integration between teams” is a complaint. “How might we establish integration standards that teams can test against continuously, so that PI System Demo preparation takes hours rather than days?” is a solvable problem that points toward a class of solutions.

Step 5: Brainstorm Solutions

With a solvable problem statement established, the group brainstorms solutions without evaluation or judgment. This is the one free-form phase. Volume matters here; more ideas create more options, and the best solution often emerges from combining elements of multiple ideas.

Jeff Sutherland’s principle applies throughout: “Fix the process, not the people.” Solutions that blame individuals or require specific people to change their behavior are fragile. Solutions that change the system, tools, processes, structures, agreements, are durable.

Step 6: Create SMART Improvement Backlog Items

The workshop concludes by converting the agreed solutions into SMART (Specific, Measurable, Achievable, Relevant, Time-bound) improvement backlog items. These items must be specific enough to be actionable, owned by a specific person or team, and scheduled to be addressed in the upcoming PI.

Vague improvement items, “improve communication,” “address technical debt”, are the raw material of the Improvement Item Graveyard. Specific improvement items, “Establish a cross-team integration testing environment by end of Week 2 of the next PI, owned by the System Architect, with success criteria of all team builds running in shared CI by Week 3”, are actionable commitments.

Fishbone Diagrams and Root Cause Identification

The fishbone diagram’s power comes from its structure. It prevents the natural human tendency to identify the first plausible cause and stop. By forcing systematic exploration across multiple causal categories, it surfaces root causes that surface-level discussion misses entirely.

In practice, facilitating a fishbone for a software delivery problem typically takes 20-25 minutes with an ART of 50-150 people, using breakout groups per causal category that report back to the full group. Each breakout group identifies three to five contributing causes in their category, which are captured on a shared whiteboard or digital collaboration tool.

Pareto Analysis for Highest-Impact Root Causes

After the fishbone generates a list of contributing causes, participants typically have 3-5 minutes of silent individual thinking before dot voting. This prevents anchoring; where the first speaker’s view disproportionately shapes group consensus.

The voting round is brief (5-7 minutes maximum) and the result is immediately visible. The RTE announces the highest-vote cause, checks for obvious objections (sometimes a minority viewpoint identifies a critical constraint that the majority missed), and confirms the root cause before proceeding to problem restatement.

Creating SMART Improvement Backlog Items

The final outputs of the Problem-Solving Workshop are improvement backlog items that will be brought to the next PI Planning event and prioritized alongside feature work (Icon Agility.

Each item should specify:

• What: The specific action to be taken
• Who: The person or team responsible
• When: The target completion date or PI iteration
• How we’ll know: The measurable success criteria

How Do You Scale I&A Across Multiple ARTs?

At a single-ART level, I&A is challenging to run well but organizationally straightforward. At Solution Train scale, multiple ARTs delivering a coordinated solution within the Large Solution SAFe configuration, I&A requires a layered approach that most large enterprises underestimate or skip entirely. The Solution Train Engineer (STE) orchestrates this layered cadence, coordinating timing across ART-level I&A events and then facilitating a Solution-level I&A that synthesizes cross-ART systemic issues (agility-at-scale.com.

The hardest problems in large-scale SAFe don’t live within ARTs; they live between them. Integration failures, architectural misalignment, conflicting PI Objectives, and cross-ART dependency failures are all problems that single-ART I&A cannot surface. Solution-level I&A exists specifically to make these inter-ART systemic issues visible. Organizations that skip it because of coordination overhead are choosing to remain blind to their most consequential organizational problems.

Layered I&A: ART-Level Then Solution-Level

The layered approach runs sequentially, not simultaneously. Each ART runs its own I&A first, producing ART-level improvement items and data. The Solution Train Engineer then synthesizes the outputs of all ART-level I&A events before facilitating the Solution-level I&A.

This sequencing matters. The Solution-level I&A should open with a synthesis of cross-ART patterns from the individual ART I&A events; which ARTs reported similar problems? Where do the same impediments appear across multiple ARTs? These convergent signals indicate systemic issues at the Solution Train level, not individual ART execution problems.

A Solution Train with three ARTs might discover that all three reported integration failures as a top problem-solving workshop focus. That convergence is a signal that the integration problem isn’t ART-specific, it’s architectural, organizational, or both, and requires Solution Train-level intervention.

The Solution Train Engineer’s Orchestration Playbook

The Solution Train Engineer’s role in scaled I&A involves:

1. Scheduling ART I&A events so they complete before the Solution-level I&A begins (typically within a two-to-three-day window at the end of the PI)
2. Collecting outputs from each ART’s Problem-Solving Workshop; specifically the improvement items created and the root causes identified
3. Synthesizing cross-ART patterns before the Solution-level I&A begins
4. Facilitating the Solution-level I&A with leadership from across the Solution Train, using ART data as the foundation for problem selection
5. Ensuring Solution-level improvement items enter the ART backlogs with appropriate priority at the next PI Planning event

Surfacing Cross-ART Systemic Issues

The epistemological challenge of Solution-level I&A is identifying problems that are only visible at the boundary between ARTs. These problems are invisible from inside any single ART: each team sees their piece of the failure but not the systemic cause.

Common cross-ART systemic issues include:

• Interface specification drift: ART A’s API outputs don’t match ART B’s API expectations because specifications diverged during the PI without formal change management
• Dependency deadlock patterns: ARTs consistently block on each other at predictable points because their PI Objectives have hidden ordering dependencies
• Architectural assumption conflicts: ARTs building to different architectural assumptions that only manifest as failures when integrated at the solution level
• Resource contention: Shared resources (DevOps teams, test environments, specialized expertise) consistently create bottlenecks that appear as ART-level delivery problems but are actually solution-level capacity problems

Remote and Distributed I&A Facilitation

Most large-scale ARTs are geographically distributed, which creates real facilitation challenges for an event designed around in-room collaboration. The tools and practices for distributed I&A facilitation have matured significantly, but the facilitation discipline required is higher, not lower.

Effective distributed I&A typically uses:

• Digital collaboration platforms (Miro, MURAL, or similar) for shared visualization of fishbone diagrams and Pareto voting
• Video conferencing with breakout rooms for small-group phases
• Asynchronous pre-work for problem candidates so the synchronous session focuses on analysis rather than problem identification
• Digital dot voting tools that provide real-time visibility to the full group

The RTE facilitating a distributed I&A needs to build in more explicit transition time between phases, more explicit instructions for each activity, and more vigilance about ensuring all participants (especially quieter participants in non-primary time zones) have opportunity to contribute.

What Are the Most Common I&A Anti-Patterns?

Six specific anti-patterns degrade I&A from a strategic improvement engine into a ceremonial checkbox; and each maps to a violation of a specific lean or agile principle. Understanding the principle violated helps leaders diagnose not just what’s going wrong but why it keeps recurring despite attempts to fix the surface behavior (Lean Wisdom.

Management Theater and the ‘Drive Out Fear’ Principle

Management Theater is the most destructive I&A anti-pattern. It occurs when leaders attend the PI System Demo, offer polite applause, and then make strategic decisions in separate meetings without referencing I&A data. The signal this sends to the ART is unambiguous: I&A is performative, not functional. The data produced doesn’t influence real decisions.

Lean principle violated: W. Edwards Deming’s 14th point; “Drive out fear, so that everyone may work effectively for the company.” When teams observe that honest I&A data (showing what didn’t get delivered and why) has no visible connection to leadership decisions, they infer that honest reporting carries risk without reward. Psychological safety, Amy Edmondson’s concept of the belief that one won’t be punished for speaking up, collapses. Teams begin optimizing I&A for appearance rather than truth.

How to fix: Leaders must visibly use I&A data in the decisions that follow the event. If PI Predictability drops to 65%, this should prompt visible inquiry: “What happened? What do teams need from us to address the root causes?” If improvement items are created in the workshop, leaders should track them and ask about them. The behavioral loop must close.

Demo-Only I&A and the Improvement Item Graveyard

Demo-Only I&A occurs when the PI System Demo is treated as the entire I&A event. The measurement review gets compressed or skipped (“we’re running behind schedule”), and the problem-solving workshop doesn’t happen. Teams demo their work, leadership applauds, and everyone moves on to post-PI activities.

The consequence is the Improvement Item Graveyard: a growing list of acknowledged problems that have never been subjected to root-cause analysis, never converted into specific improvement actions, and never scheduled for resolution. The same items appear in the graveyard PI after PI.

Lean principle violated: Deming’s Plan-Do-Check-Act cycle, specifically the Check and Act phases. Without measurement and structured problem-solving, the feedback loop is broken. The ART is running Plan-Do-Plan-Do; executing without learning.

How to fix: The RTE must protect the timebox for all three parts of I&A. When time pressure appears, the instinct to compress the workshop rather than the demo is exactly backwards: the workshop is where value is created.

Blame Sessions, Metric Gaming, and One-Size Facilitation

Blame Sessions occur when the Problem-Solving Workshop devolves into finger-pointing between teams or roles. This typically happens when psychological safety is already low and when the fishbone process is either skipped or facilitated poorly. Instead of systematic root-cause analysis, the workshop becomes a competition to assign responsibility for failures.

Lean principle violated: Jeff Sutherland’s “fix the process, not the people” principle. Blame sessions produce zero improvement because they target people rather than the system conditions that caused the problem.

Metric Gaming occurs when teams optimize their PI Predictability score rather than their actual value delivery. This manifests as artificially low planned business value (so actual scores will exceed planned scores easily), sandbagged objectives, or Business Owner scoring that inflates actual delivery to protect team relationships.

Lean principle violated: Goodhart’s Law meets Taiichi Ohno’s gemba principle. Ohno insisted that managers should “go see” actual conditions: not manage by number. When teams optimize the number rather than the underlying reality, the number becomes useless as a diagnostic.

One-Size Facilitation is the practice of running I&A identically for every PI and every ART maturity level. A brand-new ART needs a heavily facilitated, structured I&A with significant coaching on the process. A mature ART with established psychological safety may need a lighter facilitation touch and more time in the problem-solving workshop.

Lean principle violated: Respect for people; SAFe’s lean principle that teams at different maturity levels need different levels of support. Applying the same facilitation regardless of context demonstrates lack of situational awareness.

How Does I&A Drive Continuous Improvement?

I&A is not a standalone event: it is the engine that feeds the continuous improvement flywheel. But the flywheel only turns if improvement items from the workshop actually enter the ART backlog, get prioritized alongside feature work in PI Planning, and get executed in subsequent PIs. The connection between I&A output and PI Planning input is the single most important process linkage in SAFe, and it’s invisible in most ART process maps (Lean Wisdom.

Dean Leffingwell’s SAFe Principle #4, “Build incrementally with fast, integrated learning cycles”, is the architectural intent. I&A is the mechanism. But learning cycles only produce organizational capability if the insights they generate get converted into changed behavior, changed processes, or changed systems.

From I&A Output to PI Planning Input

The handoff from I&A to PI Planning requires an explicit process step that most ARTs skip: the RTE (or whoever owns the ART backlog) must bring I&A improvement items into the pre-PI Planning backlog refinement process and advocate for their inclusion in the PI’s iteration capacity.

This advocacy is necessary because improvement items compete directly with feature work for PI capacity. Product Managers and Business Owners naturally prioritize features; they’re the outputs that customers see and that business metrics measure. Improvement items feel like internal housekeeping. Without active advocacy from the RTE and Lean-Agile Leadership, improvement items consistently lose priority to features.

Protecting Improvement Capacity Against Feature Pressure

The real test of an organization’s Lean-Agile maturity is not whether they run I&A: it is whether improvement items from I&A actually get planned and executed in subsequent PIs.

The Toyota Production System (TPS) provides the model here. Toyota’s kaizen culture doesn’t leave improvement to residual capacity. It allocates specific capacity for improvement work and protects it as a strategic investment. Organizations that treat improvement as “what we do after features are done” are making a structural choice to prioritize short-term delivery over long-term organizational capability.

In practice, allocating 10-20% of PI capacity to improvement items (or equivalent in team capacity) is a reasonable starting target. Some high-performing ARTs that have invested heavily in improvement over multiple PIs find they need less improvement capacity because their system has fewer systemic problems. ARTs in early SAFe adoption typically need more.

Lean-Agile Leadership, specifically the leadership behaviors associated with SAFe’s Lean-Agile Leadership competency, plays a critical role here. Leaders who ask “what improvement items from last I&A are in this PI’s plan?” create organizational attention to the improvement backlog. Leaders who don’t ask signal that improvement items are optional.

Tracking Improvement Execution Across PIs

Improvement items that aren’t tracked don’t get done. The RTE should maintain a persistent improvement backlog that spans PIs, tracking:

• Which improvement items were created in which I&A
• Which were included in subsequent PI Planning events
• Which were completed (and when)
• Which recurred as problems in subsequent I&A events (which may indicate inadequate root-cause analysis in the original workshop)

This cross-PI tracking serves as an organizational learning record. Over time, it reveals patterns: which categories of problems recur (process issues? architectural? people/skills?), which improvement items get consistently deprioritized (revealing organizational values misalignment), and whether the overall frequency of certain problem types is decreasing (indicating systemic improvement).

Building a Kaizen Culture Through Consistent I&A Practice

The Continuous Learning Culture SAFe core competency is not built through a single I&A event or a single PI. It’s built through consistent, high-quality I&A practice over multiple PIs; where teams learn that problems identified honestly in I&A actually get addressed, that improvement items actually get prioritized, and that the organization is genuinely committed to getting better rather than just acknowledging it’s imperfect.

Toyota’s kaizen culture was built over decades of consistent practice. The concept is straightforward: small, continuous improvements compound over time into significant organizational capability. I&A is SAFe’s structural mechanism for that compounding; PI after PI, the ART systematically identifies its highest-leverage systemic problems and takes structured action to address them.

The SAFe Core Values of Relentless Improvement and Built-In Quality both depend on I&A functioning as designed. Relentless Improvement is not a slogan: it’s a practice that requires a structured mechanism. I&A is that mechanism. When it works, organizations develop genuine adaptive capacity: the ability to identify what’s constraining performance and systematically remove those constraints, PI after PI.

Summary

Inspect and Adapt (I&A) works when organizations treat it as an integrated feedback system: not three separate agenda items. The PI System Demo generates evidence of what was delivered. Quantitative measurement, anchored in the PI Predictability Measure, reveals the gap between planned and actual value. The Problem-Solving Workshop applies structured root-cause analysis to identify what’s causing that gap. Each part feeds the next, and the output feeds PI Planning, closing the loop.

The most common failure modes, running Demo-Only I&A, skipping the workshop, treating improvement items as optional, allowing Management Theater, all break the feedback loop at different points. They share a common cause: organizational pressure toward immediate delivery over systemic improvement capacity.

Before your next I&A, assess whether your current practice produces improvement items that actually get executed in the following PI. If the answer is “rarely” or “sometimes,” the issue isn’t I&A facilitation: it’s organizational commitment to the kaizen culture that I&A is designed to build. Start there.