Was ist ein PI Planning in SAFe®

PI Planning – das Event für Kommunikation und Synchronisierung

Das Program Increment (PI) Planning ist ein regelmäßig stattfindendes Ereignis bei der Anwendung des Scaled Agile Frameworks®, SAFe®. Beim PI Planning sollen alle Beteiligten eines Agile Release Trains (ART) anwesend sein, damit eine direkte Kommunikation Face-to-Face stattfinden kann. Das PI Planning bildet also auch ein soziales Konstrukt, das sowohl die einzelnen TeilnehmerInnen als auch das Kollektiv bereichert. Seit Ausbruch der COVID-19 Pandemie muss aber auch dieses Ereignis in vielen Organisationen als Online-Meeting ausgerichtet werden. Das PI Planning ist das Herzstück, der Motor oder Taktgeber des ART und richtet alle Teams auf eine gemeinsame Mission und Vision aus.

Zu den Teilnehmern der Veranstaltung gehören: Business Owners, Produktmanagement, agile Teams, System- und Lösungsarchitekten, das System Team und andere Stakeholder, die alle rechtzeitig eingeladen werden müssen, um gut vorbereitet zu sein. Die aktive Teilnahme der Business Owners an dieser Veranstaltung stellt eine wichtige Leitplanke für die Budgetplanung dar.

Was ist ein Programm-Inkrement?

Ein Programm-Inkrement (PI) ist ein Zeitraum, in dem ein Agile Release Train (ART) inkrementellen Wert in Form von funktionierender, getesteter Software oder Systemen liefert. Programm-Inkremente sind typischerweise 8 bis 12 Wochen lang. Das häufigste Muster für ein PI sind vier Entwicklungsiterationen, gefolgt von einer Innovations- und Planungsiteration (IP). Ein PI ist für einen Agile Release Train so wie eine Iteration für ein agiles Team. Es handelt sich um einen festen Zeitrahmen (Timebox), in dem die Planung, Erstellung und Validierung eines vollständigen Systeminkrements, die Demonstration des geschaffenen Werts sowie schnelles Feedback möglich ist. Jedes Programm-Inkrement wendet diese feste Abfolge (Kadenz) an, um alle Teams im ART zu synchronisieren.

Der Nutzen von PI Planning Events

PI Planning Output

Ein erfolgreiches PI Planning liefert diese zwei Ergebnisse:

• Festgelegte PI-Ziele. Das sind spezifische, messbare, akzeptierte, realistische und terminierte, kurz SMARTe Ziele, die von jedem Team erstellt werden, wobei der Geschäftswert von den Business Owners zugewiesen wird.
• Ein gemeinsames Programm-Board, das die neuen Feature-Liefertermine, Feature-Abhängigkeiten zwischen Teams und relevante Meilensteine zeigt.

Und natürlich stärkt ein solches gemeinsames Event die Zusammenarbeit im Agile Release Train. Es schärft die gemeinsame Vision steigert damit automatisch die Motivation aller Mitwirkenden.

Die Agenda eines PI Planning Events

Ein PI Planning hat eine Standardagenda, geht meistens über 2 Tage (bei mehreren Zeitzonen auch länger) und findet innerhalb der Innovations- und Planungsiteration (IP) statt. Zu Beginn werden der geschäftliche Kontext, die Produktvision und Roadmap sowie die Top 10 Features aus dem Programm Backlog präsentiert. Danach gibt es einen Ausblick auf die Architektur und Entwicklungstechniken. Der Release Train Engineer (RTE) moderiert die Veranstaltung, stellt den Planungsprozess und die erwarteten Ergebnisse des PI Plannings vor. Dann gehen die einzelnen Teams in Breakout-Sessions, wo sie Aufwände schätzen, Abhängigkeiten von Backlog Items identifizieren, die Realisierung von Features planen und einen Entwurf ihrer Planung für das nächste Inkrement erstellen. Die Entwürfe mit den noch unverbindlichen Zielen der einzelnen Teams werden in einem gemeinsamen Review vorgestellt. Abhängigkeiten, Konflikte und Ressourcenbeschränkungen werden daraufhin gemeinsam ausgehandelt und Entscheidungen getroffen, die zum Erreichen der Ziele notwendig sind.

Tag 1

Danach werden gemeinsam Programmrisiken besprochen und nach dem ROAM-Prinzip bewertet. Resolved (gelöst), Owned (jemand übernimmt für dieses Risiko die Verantwortung), Accepted (akzeptiert, dass es potenzielle Probleme geben könnte) und Mitigated (Risikoabwehr ist geplant).

Es folgt eine Vertrauensabstimmung. Die Teams stimmen über ihr Vertrauen in die Erfüllung ihrer eigenen PI-Ziele Teams ab mit einer “Faust von fünf”. Wenn der Durchschnitt bei drei gehobenen Fingern oder mehr liegt, sollte das Management die Verpflichtung akzeptieren. Wenn es weniger als drei sind, sollte das Team den Plan überarbeiten. Jeder, der Bedenken hat oder Risiken sieht, darf diese offen äußern und bei Bedarf müssen Pläne überarbeitet werden. Dann wird der Prozess für den Plan des gesamten ART wiederholt.

Falls nötig, überarbeiten Teams ihre Pläne, bis ein hohes Vertrauensniveau erreicht ist, ganz bewusst ohne Timebox. Erst wenn die Pläne Konsens finden, leitet der RTE eine kurze Retrospektive für das PI-Planning. Es folgen: gemeinsames Aufräumen, Erfassen der PI-Ziele und Stories der Teams in einem agilen Projektmanagement-Tool, Aktualisieren von Team- und ART-Kalendern, Festlegen der Orte und Zeitpunkte für die weitere Iterationsplanung.

Tag 2

Danach werden gemeinsam Programmrisiken besprochen und nach dem ROAM-Prinzip bewertet. Resolved (gelöst), Owned (jemand übernimmt für dieses Risiko die Verantwortung), Accepted (akzeptiert, dass es potenzielle Probleme geben könnte) und Mitigated (Risikoabwehr ist geplant).

Es folgt eine Vertrauensabstimmung. Die Teams stimmen über ihr Vertrauen in die Erfüllung ihrer eigenen PI-Ziele Teams ab mit einer “Faust von fünf”. Wenn der Durchschnitt bei drei gehobenen Fingern oder mehr liegt, sollte das Management die Verpflichtung akzeptieren. Wenn es weniger als drei sind, sollte das Team den Plan überarbeiten. Jeder, der Bedenken hat oder Risiken sieht, darf diese offen äußern und bei Bedarf müssen Pläne überarbeitet werden. Dann wird der Prozess für den Plan des gesamten ART wiederholt.

Falls nötig, überarbeiten Teams ihre Pläne, bis ein hohes Vertrauensniveau erreicht ist, ganz bewusst ohne Timebox. Erst wenn die Pläne Konsens finden, leitet der RTE eine kurze Retrospektive für das PI-Planning. Es folgen: gemeinsames Aufräumen, Erfassen der PI-Ziele und Stories der Teams in einem agilen Projektmanagement-Tool, Aktualisieren von Team- und ART-Kalendern, Festlegen der Orte und Zeitpunkte für die weitere Iterationsplanung.

Remote PI Planning mit verteilten Teams

Wenn ein PI Planning Event online stattfinden muss, ist unter Umständen mehr Vorbereitung notwendig. Sollten die Teams über den ganzen Erdball verteilt sein, muss bei der Planung auch die Zeitverschiebung berücksichtigt werden. Ratsam ist dann eine Ausdehnung der Agenda auf mehrere Tage. Remote PI Planning kann zusätzliche Herausforderungen in diesen Punkten mit sich bringen:

• Planung von verschiedenen Standorten
• PI-Planning Agenda mit unterschiedlichen Zeitzonen
• Raumbuchung & Technik an verschiedenen Standorten.
• Berücksichtigung aller Arbeitsvereinbarungen der Veranstaltungsteilnehmer.
• Einsatz von Technologie zur Unterstützung der verschiedenen Planungsaktivitäten.
• Moderation einer erfolgreichen verteilten PI-Planungsveranstaltung

Die Community Plattform des Scaled Agile Frameworks bietet viele Tipps und Vorlagen für registrierte Mitglieder, wie man solche Remote PI Plannings organisiert. Sicherlich nimmt die Organisation eines Remote PI Plannings mehr Zeit in Anspruch. Es empfiehlt sich, für jeden Standort einen Moderator zu haben, einen Verantwortlichen für die Technik, Audio, Video und Screensharing vorher mehrmals zu testen, mit den Teams vorher z.B. über den Scrum Master in Kontakt zu treten, mehr Puffer einzuplanen und auch für den sozialen Aspekt Programmpunkte einzuplanen (z.B. gemeinsam ein Lied singen, ein Motto für alle Teilnehmer etc.)

SAFe^® und Scaled Agile Framework^® sind Warenzeichen der Scaled Agile Inc., die auf ihrer Website www.scaledagile.com eine ausführliche Dokumentation des Frameworks veröffentlicht.