Iterationen & Eingebaute Qualität

SAFe-Iterationen sind 2-wöchige Timeboxen (gelegentlich 1 oder 3 Wochen, aber 2 ist Standard). Jede Iteration folgt einem vertrauten Zyklus:

Iterationsplanung (halber Tag) — Das Team überprüft die Iterationsziele, zieht Stories aus dem Team-Backlog, zerlegt sie in Aufgaben und verpflichtet sich zu dem, was es liefern wird. In SAFe sollten Iterationsziele mit den PI-Zielen übereinstimmen, die während der PI-Planung festgelegt wurden.

Ausführung (der Großteil der Iteration) — Das Team arbeitet an Stories, hält tägliche Standups ab und integriert kontinuierlich. Stories durchlaufen verschiedene Zustände: definiert, in Bearbeitung, fertig. Das Team verfolgt den Fortschritt im Vergleich zu seinen Iterationszielen.

Iterationsreview / System-Demo (1-2 Stunden) — Das Team demonstriert abgeschlossene Arbeit. In SAFe fließt dies in die System-Demo auf ART-Ebene ein, bei der alle Teams ihre integrierte Arbeit den Stakeholdern zeigen. Die individuelle Team-Demo ist eine Vorbereitung für die System-Demo.

Iterationsretrospektive (1 Stunde) — Das Team reflektiert, was gut lief, was nicht, und was verbessert werden kann. In SAFe können Erkenntnisse aus der Retrospektive auch in das Inspect & Adapt-Event auf PI-Ebene einfließen.

Was unterscheidet sich von eigenständigem Scrum: Die Iteration ist über alle Teams im ART synchronisiert. Alle starten und enden am selben Tag. Diese gemeinsame Kadenz schafft natürliche Integrationspunkte und macht teamübergreifende Koordination vorhersehbar.

Jedes PI enthält eine Innovation and Planning (IP) Iteration am Ende. Dies ist einzigartig für SAFe und eine seiner wertvollsten Innovationen.

Was während der IP passiert:

• PI-Planungsvorbereitung: Product Management bereitet die Vision und das Backlog für das nächste PI vor. System-Architekten bereiten die Architektur-Runway vor. Teams analysieren kommende Features.
• PI-Planungsevent: Das 2-tägige persönliche Planungsevent für das nächste PI (dies ist der Hauptzweck der IP-Iteration).
• Innovationszeit: Teams nutzen die verbleibende Zeit für Hackathons, Erkundung neuer Technologien, Abbau technischer Schulden, Schulungen oder Verfolgung von Ideen, die nicht ordentlich in ein Backlog passen.
• Inspect & Adapt: Die formale Retrospektive auf PI-Ebene, bei der das gesamte ART über quantitative Daten (Vorhersagbarkeitsmaß) und qualitative Beobachtungen reflektiert.

Warum IP wichtig ist:

Ohne dedizierte Innovationszeit häufen sich technische Schulden, Fähigkeiten stagnieren und Teams werden zu Feature-Fabriken. Die IP-Iteration ist eine strukturelle Garantie dafür, dass Verbesserung und Erkundung stattfinden – sie ist nicht davon abhängig, „Zeit zu finden", die sich nie materialisiert.

Die IP-Iteration bietet auch einen natürlichen Puffer. Wenn Teams während des PI auf unerwartete Komplexität stoßen, absorbiert die IP-Iteration den Überlauf, ohne dass Terminverlängerungen oder Scope-Kürzungen mitten in einer Iteration erforderlich sind.

SAFe ist kompromisslos in Bezug auf Qualität: Man kann nicht agil sein mit schlechtem Code. Eingebaute Qualität ist kein Nice-to-have – sie ist ein Kernwert und eine Voraussetzung für nachhaltigen Flow.

Software-Engineering-Praktiken:

• Test-Driven Development (TDD): Tests vor Code schreiben. Dies erzeugt bessere Designs und umfassende Test-Suites. Im großen Maßstab ist TDD das, was kontinuierliche Integration praktikabel macht.
• Continuous Integration (CI): Code mehrmals täglich integrieren. Automatisch bauen und testen. In SAFe erstreckt sich CI über einzelne Teams hinaus – das System muss über alle Teams im ART hinweg integrieren.
• Pair Programming / Code Review: Zwei Augenpaare bei jeder Änderung. Paare rotieren, um Wissen zu verbreiten. Code Reviews fangen Probleme ab und teilen Kontext zwischen Teammitgliedern.
• Collective Ownership: Jeder Entwickler kann jeden Teil der Codebasis ändern. Keine Wissenssilos. Dies erfordert CI und Tests, um sicher zu sein.
• Refactoring: Code-Struktur kontinuierlich verbessern, ohne das Verhalten zu ändern. Technische Schulden häufen sich im großen Maßstab schneller an, weil mehr Menschen mehr Code ändern.

Architekturpraktiken:

• Intentional Architecture: Lassen Sie Architektur nicht rein aus Team-Entscheidungen entstehen. System-Architekten leiten übergreifende Belange, stellen sicher, dass Teams auf gemeinsamen Plattformen aufbauen, und pflegen Architektur-Runway für zukünftige Features.
• Architectural Runway: Investieren Sie im Voraus in Infrastruktur, Frameworks und technische Enabler, die zukünftige Features benötigen werden. Ohne Runway beginnt jedes Feature bei Null.

Warum Qualität im großen Maßstab mehr zählt:

Bei einem Team bedeutet schlechte Qualität langsame Lieferung. Bei zehn Teams bedeutet schlechte Qualität kaskadierende Integrationsfehler, gegenseitige Schuldzuweisungen und Systemfehler, die niemand besitzt. Die Kosten von Qualitätsproblemen wachsen überlinear mit der Teamanzahl.