Das PI-Planning im Scaled Agile Framework

PI-Planning im Scaled Agile Framework

Das PI-Planning im Scaled Agile Framework ist ein, wenn nicht das, zentrale Synchronisationsmeeting im Skalierungsframework der Scaled Agile Inc. Das PI-Planning ist ein Event, dass Sie definitiv nicht weglassen können und dem Sie einiges an Vorbereitung für die korrekte und effiziente Durchführung spendieren sollten. Wenn Sie das PI-Planning nicht durchführen, machen Sie auch kein SAFe, so die Aussage der Autoren.

There is no magic in SAFe … except maybe for PI Planning.

SAFe

PI-Planning steht für Program Increment Planning und stellt die nächste, unmittelbare Planung dar, die auf der sogenannten Program Ebene in SAFe durchgeführt wird.

Das PI-Planning dauert zwei Tage und erwartet die Teilnahme aller Beteiligten. Die Teilnahme wird zudem von Angesicht zu Angesicht durchgeführt. Das kann bedeuten, dass Sie die gesamte Projektmanschaft an einen Ort bringen müssen. Für das PI-Planning entstehen also einiges an Kosten, die aber gut investiert sind. Und aus der Erfahrung: ja, es müssen alle an diesem Event teilnehmen. Ähnliche Überlegungen und Aussagen stecken im agilen Manifest als Prinzipien.

Der Ablauf eines PI-Planning

In diesem Abschnitt gehe ich einmal auf alle Details eines typischen Ablaufs des PI-Plannings ein. Das PI-Planning ist über zwei Tage angelegt und SAFe bringt eine Standardagenda mit. Es lohnt sich zu Beginn genau diese Agenda auch zu verwenden und Sie tun gut daran, sich gerade für diese beiden Tage eine entsprechende Unterstützung zu holen. Erfahrungen helfen bei der erfolgreichen Durchführung eines PI-Planning enorm.

Die Voraussetzungen für ein PI-Planning

Das PI-Planning ist ein sehr aufwändiges Meeting. Eine entsprechende gründliche und sorgsame Vorbereitung ist daher erforderlich.

  • Das Produktmanagement muss zunächst einmal ein einheitliches und gleiches Verständnis für die umzusetzenden Aufgaben haben. Das klingt zwar logisch, ist in der Realität aber oft anders anzutreffen.
  • Sind die Voraussetzung für den ART (agile Release Train) gegeben? Die Teams sollten das Verständnis haben, was eine lean / agile Entwicklung bedeutet. Die entsprechenden Rollen müssen benannt und etabliert sein.
  • Die Vision muss durch das Management bereit gestellt werden. Zudem muss natürlich auch das Backlog vorhanden und gefüllt sein. Zudem gibt es die „Regel“ das die TOP-10-Features durch das Management vorgestellt werden. Ebenso folgt eine Übersicht über sogenannte Enabler.
  • Ein ganz wichtiger Punkt betrifft natürlich die Infrastruktur. Wenn Sie sich vorstellen, dass bei einem PI-Planning bis zu 150 Personen gemeinsam planen, dann benötigen Sie Räumlichkeiten, Catering, organisatorische Planungen für den Tag und eine funktionierende Infrastruktur für die Kommunikation, wenn remote noch weitere Personen zugeschaltet werden sollen, bedarf es auch hier einiges an sorgfältiger Planung.

Die Durchführung eines PI-Planning

Für die Durchführung des PI-Plannings gibt es vom Scaled Agile Framework eine Standardagenda, an die sich die Beteiligten halten können.

PI-Planning: Agenda für zwei Tage

Die Agenda für das PI-Planning aus dem Scaled Agile Framework

Sie gibt einen guten ersten Startpunkt, um die eigene Agenda nicht komplett „von scratch“ zu entwickeln.

Der erste Tag des PI-Planning

  • Für rund eine Stunde wird der Business Kontext vorgestellt. Das wird durch einen verantwortlichen Manager verantwortet und nicht deligiert. Dabei wird der geschäftliche Kontext dargestellt, in dem sich die Entwicklung bewegt.
  • Durch den verantwortlichen Produktmanager wird die Produktvision vorgestellt. Dabei wird auch der – wie oben angedeutete – TOP-10-Feature Überblick mit vorgestellt.
  • In dem Abschnitt der Architekturvision und Entwicklungspraktiken stellt der Enterprise-Architekt / Systemarchitekt die aktuelle Architekturvision. Zudem können nach Änderungen / Neuheiten hinsichtlich Entwicklungspraktiken vorgestellt werden.
  • Das Planungskonzept wird durch den RTE (Release Train Engineer) vorgestellt. Dabei geht es um den organisatorischen und inhaltlichen Ablauf. Das bietet sich noch vor der Mittagspause an, die gemeinsam dann verbracht wird.
  • Der erste große Block eigentlicher Arbeit wird in den Teammeetings erbracht. Die Teams arbeitet zunächst einmal für sich und erstellen einen ersten Plan auf, wie das Team mit den vorhandenen Aufgaben umgehen will. Dabei schätzt das Team ebenso die zur Verfügung stehende Kapazität in diesem Sprint und brechen dann die Stories in konkrete Aufgaben herunter. Hier kommen in der Regel auch die Risiken und Abhängigkeiten zum Vorschein – als Ergebnis gibt es dann die Ziele für das Program Increment von diesem Team.
  • Dann folgt ein gemeinsamer Review Termin. Hier wird das Ergebnis der Teams vorgestellt. Dabei wird der Fokus auf die zu erreichenden Ziele, ggf. Risiken und Abhängigkeiten gelegt. Das Feedback aller Beteiligten ist ein wichtiger Input für die spätere Verfeinerung und Überprüfung, ob das gemeinsame Verständnis vorliegt.
  • Den Abschluss an dem ersten Tag macht das Management mit einem Review. Dabei kommen Probleme zur Sprache, die vorher durch die Teams in Form von Abhängigkeiten entdeckt wurden. Der RTE ist hier wieder der entscheidene Facilitator, der die Fäden in der Hand hält.

Der zweite Tag des PI-Planning

  • Der zweite Tag startet mit einer Anpassung der Planung. Diese resultiert aus der letzten Aktion des vergangen Tages. Das kann zum Beispiel ein geänderter Umfang oder eine angepasste Kapazität sein.
  • In einem zweiten Teammeeting, das identisch vom Vortag ist, planen die Teams erneut mit den aus der zuvorgenannten Anpassung der Planung neuen Erkenntnissen. Dabei stehen die Ziele in Form von Objectives und Strech Objectives erneut zur Prüfung.
  • Vor dem Mittag findet dann das finale Planreview des PI-Plannings statt.
  • Da Sie sich hier auf der Ebene des Program Levels befinden, werden im Anschluss noch die Programmrisiken adressiert, die die Teams in ihren vorherigen Teammeetings gefunden haben. Dazu schlägt SAFe das ROAM vor, das steht für resolved, owned, accepted und mitigated.
  • Dann folgt der Confidence Vote, bei dem alle Teammitglieder mit Fingerzeichen (1,2,3,4 oder 5) Ihre Zustimmung für die Planung geben. Dabei wird oft angenommen, dass bei einem Durchschnitt von drei Finger oder mehr das Management die Planung als Commitment akzeptiert.
  • Sollte der Fall sein, dass zu wenig Übereinstimmung und Akzeptanz zu der Planung vorliegt, dann muss erneut in eine Verhandlung gegangen werden. Hier liegt dann der Fokus auf dem gemeinsamen Verständnis. Sehr wahrscheinlich kann dann die Timebox eh nicht mehr eingehalten werden, weshalb der Fokus in so einem Fall dann mehr auf dem gemeinsamen Verständnis als der Timebox liegt.
  • Zum Schluss gibt es noch eine Retrospektive.

Das Ergebnis eines PI-Planning

Am Ende eines PI-Plannings sind die folgenden Dinge bekannt und erarbeitet

  • Jedes der Teams hat seine Ziele formuliert, alle nötigen Entscheidungen für das Program Increment getroffen.
    • Objectives liegen vor und
    • die Strech Objectives sind bestimmt
  • Das gemeinsame Verständnis über das was erstellt werden soll, ist bei allen Personen getroffen
  • Die Business Owner & sonstigen Stakeholder kennen die Geschwindigkeit, die die Teams leisten können und haben die Erwartung hinsichtlich umzusetzender Aufgaben konsolidiert
  • Ein sogeannter Confidence Vote, der ein gemeinsames Bild über die realistische Erreichen des Ziels für das Program Increment angibt

Take-aways

Das PI-Planning ist ein schon fast zeremoniell geplantes und heiliges Instrument im Scaled Agile Framework. Ob man SAFe nun mag oder nicht, Sie benötigen immer dann, wenn Sie Produkte mit mehreren Teams entwickeln eine Möglichkeit, diese zu synchronisieren. Das PI-Planning ist dabei eine Möglichkeit. Andere Modelle verwende andere Verfahren, aber der Kern bleibt: Das Team muss sich zur Planung treffen und das am besten auch vor Ort – auch oder vielleicht gerade in einer verteilten und digitalen Welt. Den sozialen und menschlich Aspekt außen vor zu lassen, wird sich später rächen.

Leave a Reply 0 comments

Leave a Reply:







Verbessere dein Projektmanagement. Mit Scrum.

x