System Demo & Inspect and Adapt

Die System Demo findet am Ende jeder Iteration statt. Anders als einzelne Team-Demos, die die Arbeit jedes Teams isoliert zeigen, präsentiert die System Demo integrierte, funktionierende Software über alle Teams des ART hinweg.

Warum systemweite Integration wichtig ist:

Einzelne Team-Demos können großartig aussehen, während das Gesamtsystem defekt ist. Team A hat seine API fertiggestellt. Team B hat sein UI fertiggestellt. Aber sie haben nie integriert – und wenn sie es tun, funktioniert nichts. Die System Demo erzwingt diese Integration alle 2 Wochen, nicht erst am Ende des PI, wenn es zu spät ist.

Eine effektive System Demo durchführen:

• Vorbereitung: Das ART integriert die gesamte Teamarbeit vor der Demo in eine Staging-Umgebung. CI/CD-Pipelines sollten dies automatisch erledigen – wenn Sie einen „Hardening-Sprint" zur Integration benötigen, ist Ihre CI defekt.
• Publikum: Stakeholder, Business Owner, Management. Dies ist ihr Einblick in den Entwicklungsfortschritt. Machen Sie es für nicht-technische Personen zugänglich.
• Format: Zeigen Sie funktionierende Software, keine Folien. Demonstrieren Sie End-to-End-Szenarien, die Teamgrenzen überschreiten. Heben Sie hervor, was neu ist, was sich geändert hat und welche Risiken bestehen.
• Dauer: 1–2 Stunden, abhängig von der ART-Größe.
• Feedback: Fordern Sie aktiv Feedback ein. Was funktioniert? Was fehlt? Was muss sich ändern? Dieses Feedback prägt die Prioritäten der nächsten Iteration.

Die System Demo ist der primäre Rechenschaftsmechanismus des ART. Sie können Fortschritte in Statusberichten verbergen. In einer Live-Demo funktionierender Software können Sie sie nicht verbergen.

Inspect and Adapt (I&A) ist die Retrospektive auf PI-Ebene retrospective. Sie findet am Ende jedes PI (während der IP-Iteration) statt und umfasst das gesamte ART. Während Team-Retrospektiven sich auf Verbesserungen auf Teamebene konzentrieren, adressiert I&A systemische Probleme, die sich über Teams erstrecken.

Das I&A-Event besteht aus drei Teilen:

1. PI System Demo (1–2 Stunden) — Eine umfassende Demo von allem, was während des PI geliefert wurde. Dies ist die finale, definitive System Demo, die das vollständige Wertinkrement zeigt. Business Owner bewerten den tatsächlich gelieferten Wert im Vergleich zu den PI-Zielen.

2. Quantitative Messung (30 Min.) — Überprüfung objektiver Daten:

• Vorhersagbarkeitsmaß: Geplanter vs. tatsächlicher Business Value (jedem PI-Ziel wurde ein Business Value zugewiesen; wie viel wurde geliefert?)
• Velocity-Trends: Beschleunigen, stabilisieren oder verlangsamen sich die Teams?
• Flow-Metriken: Lead Time, Durchsatz, WIP-Trends
• Qualitätsmetriken: Defekt-Trends, entkommene Defekte, Testabdeckung

3. Problem-Solving-Workshop (1,5–2 Stunden) — Der wertvollste Teil. Das ART identifiziert die wichtigsten Probleme und nutzt strukturiertes Problem-Solving:

• Brainstorming von Problemen (alle tragen bei)
• Abstimmung über die wirkungsvollsten zu lösenden Probleme
• Ursachenanalyse (5 Whys, Fishbone-Diagramm)
• Definition von Verbesserungs-Stories mit klaren Akzeptanzkriterien
• Hinzufügen von Verbesserungs-Stories zum Backlog des nächsten PI

Das Ergebnis von I&A sind konkrete Verbesserungselemente, die in das Programm-Backlog eingehen. Dies sind keine vagen Absichten – es sind geschätzte Stories mit Verantwortlichen, die im nächsten PI um Kapazität konkurrieren.

Der schwierigste Teil kontinuierlicher Verbesserung ist nicht die Identifikation von Problemen – es ist die Umsetzung. I&A produziert Verbesserungs-Stories, aber diese Stories müssen tatsächlich erledigt werden.

Strategien für nachhaltige Verbesserung:

• Behandeln Sie Verbesserungs-Stories wie Feature-Stories: Sie kommen auf das Board, sie haben Akzeptanzkriterien, sie werden gedemoet. Verstecken Sie sie nicht in einer separaten „Tech-Debt"-Liste, die niemand anschaut.
• Kapazität zuweisen: Reservieren Sie 10–20 % der Kapazität jedes Teams für Verbesserungsarbeit. Machen Sie dies während des PI Planning explizit.
• Verbesserungsmetriken verfolgen: Werden Lead Times kürzer? Verbessert sich die Vorhersagbarkeit? Steigt die Qualität? Wenn Ihre Verbesserungs-Stories die Metriken nicht bewegen, lösen Sie die falschen Probleme.
• Retrospektive der Retrospektiven: Überprüfen Sie regelmäßig, ob I&A tatsächlich Veränderungen bewirkt. Tauchen PI für PI dieselben Probleme auf? Wenn ja, ist die Ursachenanalyse nicht tiefgehend genug.
• Erfolge feiern: Wenn eine Verbesserungs-Story ein langjähriges Problem löst, würdigen Sie dies. Das verstärkt die Verbesserungskultur.

Das Vorhersagbarkeitsmaß:

SAFe verwendet eine spezifische Formel: Summe des erreichten Business Value ÷ Summe des geplanten Business Value × 100 %. Ein gesundes ART erzielt konstant 80–100 %. Unter 80 % deutet auf Planungsprobleme hin (Überengagement, schlechte Schätzung oder zu viele ungeplante Störungen).

Vorhersagbarkeit bedeutet nicht Perfektion – es geht darum, das Vertrauen aufzubauen, das es dem Business ermöglicht, um die Lieferung herum zu planen. Ein ART, das zuverlässig 85 % des zugesagten Werts liefert, ist unendlich wertvoller als eines, das 100 % verspricht und unvorhersehbar liefert.