Simyl
simylflow
Course Home
Module 3: Program Level (ART)
Lesson 3 of 3
18 min

System Demo & Inspect and Adapt

How system-level demos drive feedback and how Inspect & Adapt creates structured improvement.

1System Demo

The System Demo happens at the end of every iteration. Unlike individual team demos that show each team's work in isolation, the System Demo shows integrated, working software across all teams on the ART.

Why system-level integration matters:

Individual team demos can look great while the overall system is broken. Team A completed their API. Team B completed their UI. But they never integrated—and when they do, nothing works. The System Demo forces this integration to happen every 2 weeks, not at the end of the PI when it's too late.

Running an effective System Demo:

  • Preparation: The ART integrates all team work into a staging environment before the demo. CI/CD pipelines should make this automatic—if you need a "hardening sprint" to integrate, your CI is broken.
  • Audience: Stakeholders, business owners, management. This is their window into development progress. Make it accessible to non-technical people.
  • Format: Show working software, not slides. Demonstrate end-to-end scenarios that cross team boundaries. Highlight what's new, what changed, and what risks remain.
  • Duration: 1-2 hours, depending on ART size.
  • Feedback: Actively solicit feedback. What's working? What's missing? What needs to change? This feedback shapes the next iteration's priorities.

The System Demo is the ART's primary accountability mechanism. You can hide progress in status reports. You can't hide it in a live demo of working software.

Demo Anti-Patterns

If your System Demo is a slide deck, a video recording, or a 'walk-through' of code, it's not a demo. Show the running system. If the system doesn't run, that's the most important thing to demo—and fix.

2Inspect and Adapt

Inspect and Adapt (I&A) is the PI-level retrospective. It happens at the end of each PI (during the IP iteration) and involves the entire ART. While team retrospectives focus on team-level improvements, I&A addresses systemic issues that span teams.

The I&A event has three parts:

1. PI System Demo (1-2 hours) — A comprehensive demo of everything delivered during the PI. This is the final, definitive System Demo showing the full increment of value. Business Owners assess actual value delivered against PI objectives.

2. Quantitative Measurement (30 min) — Review objective data:

  • Predictability Measure: Planned vs. actual business value (each PI objective was assigned a business value; how much was delivered?)
  • Velocity trends: Are teams accelerating, stabilizing, or slowing?
  • Flow metrics: Lead time, throughput, WIP trends
  • Quality metrics: Defect trends, escaped defects, test coverage

3. Problem-Solving Workshop (1.5-2 hours) — The most valuable part. The ART identifies the top problems and uses structured problem-solving:

  • Brainstorm problems (everyone contributes)
  • Vote on the most impactful problems to solve
  • Root cause analysis (5 Whys, Fishbone diagram)
  • Define improvement stories with clear acceptance criteria
  • Add improvement stories to the next PI's backlog

The output of I&A is concrete improvement items that go into the program backlog. These aren't vague intentions—they're estimated stories with owners that compete for capacity in the next PI.

3Making Improvement Stick

The hardest part of continuous improvement isn't identifying problems—it's following through. I&A produces improvement stories, but those stories need to actually get done.

Strategies for making improvement stick:

  • Treat improvement stories like feature stories: They go on the board, they have acceptance criteria, they get demoed. Don't hide them in a separate "tech debt" list that nobody looks at.
  • Allocate capacity: Reserve 10-20% of each team's capacity for improvement work. Make this explicit during PI Planning.
  • Track improvement metrics: Are lead times getting shorter? Is predictability improving? Is quality trending up? If your improvement stories aren't moving the metrics, you're solving the wrong problems.
  • Retrospective of retrospectives: Periodically review whether I&A is actually driving change. Are the same problems surfacing PI after PI? If so, the root cause analysis isn't deep enough.
  • Celebrate wins: When an improvement story resolves a long-standing pain point, acknowledge it. This reinforces the improvement culture.

The predictability measure:

SAFe uses a specific formula: sum of achieved business value ÷ sum of planned business value × 100%. A healthy ART scores 80-100% consistently. Below 80% suggests planning issues (overcommitting, poor estimation, or too many unplanned disruptions).

Predictability isn't about perfection—it's about building the trust that allows the business to plan around delivery. An ART that reliably delivers 85% of committed value is infinitely more valuable than one that promises 100% and delivers unpredictably.

The Improvement Backlog

Keep a persistent improvement backlog across PIs. Some improvements take multiple PIs to implement. Tracking them in one place prevents good ideas from getting lost in the shuffle.

Key Takeaways
  • System Demos show integrated working software across all teams every iteration
  • Inspect & Adapt combines quantitative measurement with structured problem-solving
  • I&A produces improvement stories that go into the program backlog
  • Predictability measure (80-100%) builds business trust in delivery