PI Planning

PI Planning ist das wichtigste Event in SAFe. Hier kommt der gesamte ART – jedes Team, jede Rolle – zusammen, um das nächste Program Increment zu planen.

Warum lohnt sich die Investition in eine persönliche Planung mit 50-125 Personen?

1. Ausrichtung im großen Maßstab: Alle hören dieselbe Vision, dieselben Prioritäten, dieselben Rahmenbedingungen. Fehlausrichtungen, deren Entdeckung und Behebung sonst Wochen dauern würde, werden in Stunden aufgedeckt und gelöst.

2. Abhängigkeitsmanagement: Teams identifizieren Abhängigkeiten zu anderen Teams während der Planung, nicht während der Entwicklung, wenn es zu spät ist, um anzupassen. Das Program Board macht Abhängigkeiten auf einen Blick sichtbar.

3. Gemeinsames Commitment: Teams committen sich auf Ziele, die sie mitgestaltet haben. Das ist keine Top-down-Zuweisung – es ist eine kollaborative Verhandlung. Menschen committen sich stärker auf Pläne, die sie mitgeformt haben.

4. Soziale Verbindung: Menschen bauen Vertrauen durch persönliche Interaktion auf. Zwei Tage gemeinsamer Arbeit schaffen mehr Vertrauen als Monate von Slack-Nachrichten. Vertrauen ist die Währung, die teamübergreifende Koordination funktionieren lässt.

5. Schnelle Problemlösung: Wenn 100+ Personen im selben Raum sind, werden Probleme in Minuten gelöst, die per E-Mail Tage dauern würden. Eine Anforderung klären? Zehn Schritte gehen. Eine Abhängigkeit verhandeln? Das Gespräch jetzt führen.

PI Planning findet typischerweise alle 8-12 Wochen statt. Die Investition ist erheblich (2 Tage × 100 Personen = 200 Personentage), aber der Ertrag – in Form von Ausrichtung, reduzierter Nacharbeit und schnellerer Lieferung – rechtfertigt die Kosten durchweg.

PI Planning folgt einem strukturierten zweitägigen Format:

Tag 1:

• Geschäftskontext (1 Stunde) — Die Führungsebene präsentiert die aktuelle Geschäftssituation, Marktdynamiken und strategische Prioritäten. Das ist das „Warum" hinter dem kommenden PI.
• Produkt-/Lösungsvision (1 Stunde) — Product Management präsentiert die wichtigsten Features für das PI, erklärt Prioritäten und beantwortet Fragen. Das ist das „Was".
• Architekturvision (30 Min.) — Der System Architect präsentiert die technische Richtung, den Status der Architectural Runway und übergreifende Belange. Das ist das „Wie" auf hoher Ebene.
• Team-Breakouts (3-4 Stunden) — Teams gehen in ihre Teambereiche und planen. Sie zerlegen Features in Stories, identifizieren Abhängigkeiten, schätzen Kapazität und entwerfen ihre PI-Ziele. Hier passiert die eigentliche Arbeit.
• Entwurfsplan-Review (2 Stunden) — Jedes Team präsentiert seinen Entwurfsplan (2 Minuten pro Team) dem gesamten ART. Andere Teams hören auf Abhängigkeiten und Konflikte.

Tag 2:

• Planungsanpassungen (1-2 Stunden) — Basierend auf dem Entwurfsplan-Review passen Teams ihre Pläne an. Abhängigkeiten werden verhandelt. Der Scope wird angepasst. Product Management kann basierend auf dem, was Teams gelernt haben, neu priorisieren.
• Finaler Plan & Confidence Vote (1 Stunde) — Jedes Team präsentiert seine finalen PI-Ziele und der ART stimmt über das Vertrauen ab. Alle halten 1-5 Finger hoch. Wenn das durchschnittliche Vertrauen unter 3 liegt, diskutiert der ART und plant neu, bis sich das Vertrauen verbessert.
• PI Planning Retrospektive (30 Min.) — Kurze Retro zum Planungsevent selbst. Wie können wir PI Planning beim nächsten Mal besser machen?

Das Program Board ist ein physisches (oder digitales) Artefakt, das Abhängigkeiten über Teams und Iterationen hinweg sichtbar macht.

Struktur: Ein Raster mit Teams als Zeilen und Iterationen als Spalten. Teams platzieren Feature-Karten in der Iteration, in der sie daran arbeiten wollen. Abhängigkeitsfäden (buchstäblich farbiges Garn auf einem physischen Board) verbinden Karten zwischen Teams.

Was das Program Board offenbart:

• Welche Teams an welchen Features in welchen Iterationen arbeiten
• Teamübergreifende Abhängigkeiten (die Fäden zwischen Karten)
• Meilensteine und Lieferverpflichtungen
• Potenzielle Engpässe (zu viele Fäden, die auf ein Team zeigen)

Das Board lesen:

• Rote Fäden = risikoreiche Abhängigkeiten (teamübergreifend, harte Deadlines)
• Häufung von Fäden = ein Team ist ein Engpass oder Single Point of Failure
• Fäden über viele Iterationen = lange Abhängigkeitsketten, die das Risiko erhöhen
• Leere Zeilen = Team mit unklaren Zielen (untersuchen)

Das Program Board ist eines der mächtigsten Artefakte von SAFe, weil es unsichtbare Koordinationsprobleme in sichtbare, handhabbare verwandelt. Ein volles Board mit vielen Fäden ist kein Scheitern – es ist eine ehrliche Darstellung der Realität, die Sie jetzt angehen können.

Strategien für Abhängigkeitsmanagement:

• Stories neu ordnen, um Abhängigkeiten zuerst zu liefern
• Teams paaren, um an gemeinsamen Komponenten zu arbeiten
• Gemeinsame APIs oder Verträge erstellen, die Teams entkoppeln
• Die Abhängigkeit akzeptieren und mit regelmäßigen Sync-Meetings managen