Was ist ein PI Planning Event? Wie bereitet man es vor und nach? Wie führt man es durch?
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.
Scaled Agile Inc.
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.
Um ein PI Planning erfolgreich durchzuführen, muss man organisatorisch, inhaltlich und logistisch gut vorbereitet sein. Inhaltlich müssen für den Auftakt der Veranstaltung Präsentationen von:
abgestimmt und ausgearbeitet sein. Organisatorisch muss der Agile Release Train fahrbereit sein, d.h. Teams, Rollen, Planungsumfang und -prozess müssen allen klar sein und logistisch braucht eine solche Großveranstaltung ebenfalls eine gute Vorbereitung (Raumbuchung, Anreise, Technik, Verpflegung etc.).
Ein erfolgreiches PI Planning liefert diese zwei Ergebnisse:
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.
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.
Am zweiten Tag stellt zunächst das Management alle Änderungen an Planungsumfang, Mitarbeitereinsatz und Ressourcen vor. Dann setzen die Teams in Breakout-Sessions die Planung vom Vortag fort. Sie legen ihre Team-Ziele für das PI fest und die Business Owners weisen diesen Zielen jeweils einen Geschäftswert zu. Zurück im Plenum stellen alle Teams Ihre Pläne vor. Risiken und mögliche Einschränkungen werden dem RTE ebenfalls mitgeteilt. Danach holt jedes Team öffentlich bei den Business Owners eine Zustimmung ein. Wenn der Plan akzeptiert wird, hängt das Team sein PI-Zielblatt an ein gemeinsames Board, damit alle Beteiligten einen Blick in Echtzeit auf die Gesamtziele erhalten. Sollten die Business Owners Bedenken haben, bekommen betreffende Teams die Möglichkeit, ihre Pläne nach Bedarf anzupassen. Diese stellen dann natürlich noch einen überarbeiteten Plan vor.
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.
Dean Leffingwell
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:
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.
