Das PI-Planning ist eines, wenn nicht das zentrale Event, aus dem Scaled Agile Framework. Es dient dazu das sich die Agile Release Trains (auch ART genannt, eine Gruppe von Teams) für das nächste Program Increment (PI) auf die gemeinsame Vision ausrichten und sich synchronisieren. In diesem Artikel betrachte ich das PI-Planning vom Inhalt, beleuchte die unterschiedlichen Aspekte. Ich möchte dabei keine Grundsatzdiskussionen über das richtige Framework starten, sondern dieses Event im Kontext sehen.
Das PI-Planning im Scaled Agile Framework
Das Scaled Agile Framework nutzt sogenannte Program Increments (PI), um eine große Anzahl an Menschen miteinander agieren und austauschen zu lassen, sich Pläne zu überlegen sowie die wichtigsten Informationen von Management und ART mitzubekommen. Wenn du das PI-Planning noch nicht kennst, dann kannst du es - ganz abstrakt gesehen - mit einer großen Sprint Planung vergleichen.
Wenn du Large Scale Scrum (LeSS) kennst, dann wird dir das PI-Planning sehr formal und überstrukturiert vorkommen. Wo das LeSS einen mehr selbstorganisierten und dezentralen Ansatz verfolgt, ist im Scaled Agile Framework viel vorgeben. So besitzt das PI-Planning eine doch recht harte Vorgabe an Zeiten, die an diesem Event zu erfolgen sind. Dabei ist dieses Event auf 2 Tage angesetzt.
Im SAFe sagt man gerne, dass das PI-Planning das Herzstück ist und es eigentlich keine Magie gibt, mit Ausnahme vielleicht des PI-Plannings. Alle Teams, die in einem ART sind, planen gemeinsam und brechen dabei “große Arbeit” in kleinere herunter. Am Ende steht also ein Plan, der mit User Stories aufgebaut ist. Damit der ART und dann die Teams auch zu diesen User Stories kommen, bedienen die sich sogenannter Features. Wenn du SAFe nicht kennst, sagt dir der Begriff von EPICs bestimmt was. Also etwas, was nicht in einen Sprint passt und somit erstmal “größer” ist. Der Begriff des EPICs gibt es im SAFe auch. Das ist aber noch einmal eine andere "Flugebene". Wir sprechen von Features, wenn es um den Eingang in das PI-Planning geht.
Nach etwas Magie und zwei Tagen ist das Ergebnis des PI-Plannings dann ein abgestimmter Plan zwischen den Teams, der dann für das nächste Quartal steht. Dann gehen alle Teams wieder auseinander und arbeiten in Sprints.
Und hier siehst du auch den großen Unterschied zwischen dem Ebenen- und Einheitenmuster. Hier hast du eine weitere “Ebene”, nämlich die des PI, die “über” den Teams liegt. Schauen wir uns LeSS an, dann gibt es das nämlich genau nicht (und auch nicht in Scrum). Beide sind immer eine “Einheit”. Auch hier lasse ich das mal so stehen, ungeachtet ob das für den einen gut oder schlecht ist - es sind unterschiedliche Ansätze.
Achtung: In Scaled Agile Framework werden immer und immer wieder die gleichen SAFe-Fehler gemacht. Schau dir dazu auch unbedingt die Auflistung auf meiner Seite an.
Die Vorteile des PI-Plannings
Aus Sicht von SAFe gibt es eine Reihe von Vorteilen, die durch ein PI Planning erreicht werden. Dazu zählen die folgenden Dinge:
- Aufbau der sozialen Verbindungen, auf denen der ART beruht.
Dadurch, dass die Teilnehmer im PI-Planning zusammenkommen und sich sehen, miteinander reden (können), wird die persönliche (Face-to-Face) Kommunikation zwischen allen Teammitgliedern und Stakeholdern gefördert.
Die Entwicklung wird ein einem PI-Planning an den Geschäftszielen, dem Kontext der Vision und den
PI-Objectives ausgerichtet.
SAFe geht von Abhängigkeiten zwischen den Teams aus und setzt auf die Identifizierung dieser und fördert dafür auch die team- und ART-übergreifenden Zusammenarbeit in einem PI-Planning.
Es erfolgt ein Abgleich zwischen den Anforderungen (was zu tun ist) und der vorhandenen Kapazität der Teams.
Wenn alle Personen zusammen sind, wird die schnelle Entscheidungsfindung gefördert und Themen können schnell geklärt werden.
Voraussetzungen
Damit ein PI-Planning gut funktioniert, müssen - wenig überraschend - die Anforderungen, die geplant und bearbeitet werden sollen, klar sein. So erwartet man in diesem Kontext, dass...
- ... die Vision vorliegt
- ... die Roadmap existiert
- ... die TOP-10 Features aufbereitet sind
vorbereitet sind und vorliegen. Wenn du jetzt wieder von der “nicht SAFe” Seite schaust, dann entdeckst du hier auch Ähnlichkeiten. Eine Vision sollte dir keine Fragezeichen auf die Stirn zaubern, eine Roadmap kannst du am ehesten mit einer Story Map vergleichen und TOP 10 Features sind dann praktisch große Anforderungen, die eben noch keine User Stories sind.
Durchführung des PI-Plannings
Die Durchführung eines solchen Program Increment Plannings wird über genau zwei Tage veranstaltet.
Tag 1
Der Tag wird mit dem Geschäftskontext begonnen. Darunter verstehen wir im Scaled Agile Framework, dass ein Business Owner (oder sonst oft anderer Manager) den aktuellen Zustand / Situation über das Unternehmen vorstellt, die Vision ins Gedächtnis ruft und einen Ausblick gibt, wie effektiv die bestehenden Lösungen die aktuellen Kundenbedürfnisse adressieren.
Produkt & Lösungen - Das Produktmanagement stellt die aktuelle Vision anhand der TOP-10-Features genauer vor und stellt die Änderungen gegenüber des vorherigen PI-Plannings sowie zukünftiger Meilensteine hervor.
Architekturvision und Entwicklungspraktiken - Der Systemarchitekt (oder Engineering) stellt die Architekturvision vor. Außerdem kann ein Senior Development Manager unterstützende Änderungen an den (agilen) Entwicklungspraktiken vorstellen, wie z. B. Testautomatisierung, DevOps oder auch Continuous Integration / Deployment.
Planungskontext und Mittagessen - Der RTE (Release Train Engineer) stellt den Planungsprozess und die erwarteten Ergebnisse des Meetings vor.
1. Team-Breakouts-Sessions - In dieser Breakout-Session schätzen die Teams ihre Kapazität für jede Iteration und identifizieren die Backlog-Elemente, die sie wahrscheinlich benötigen werden, um die Features zu realisieren. Jedes Team erstellt seine Planentwürfe, die für alle sichtbar sind, Iteration für Iteration.
Draft Plan Review - Die Teams präsentieren die wichtigsten Planungsergebnisse, darunter Dinge wie Kapazität und Auslastung, PI-Entwurfsziele, potenzielle Risiken und Abhängigkeiten. Business Owner, Produktmanagement und andere Teams und Stakeholder prüfen und liefern Input.
Überprüfung durch das Management und Problemlösung - Häufig ergeben sich Änderungsbedarfe an den Plänen, die das Management mit Teams / Vertretern aushandeln und lösen kann.
Tag 2
Planungsanpassungen - Am nächsten Tag beginnt die Veranstaltung mit der Präsentation von Änderungen des Planungsumfangs, der Personen und der Ressourcen durch das Management.
2. Team Breakout-Session - Die Teams arbeiten weiter an ihren Plänen mit dem Input aus der Plananpassung (das kann auch mal keine sein) und verfeinern ihre Pläne. Sie legen ihre Ziele für das PI fest, denen die Business Owner einen Geschäftswert zuweisen.
Abschließendes Planreview und Mittagessen - In dieser Sitzung stellen alle Teams ihre Pläne der Gruppe vor. Zum Schluss gibt jedes Team seine Risiken und Hindernisse an, die Rücksprache mit den Business Ownern erfolgt und die finalen Ergebnisse werden präsentiert und zwar so, dass jeder sehen kann, wie die Gesamtziele aussehen.
Risiken - Während der Planung haben die Teams Risiken und Hindernisse identifiziert, die die Ziele beeinträchtigen könnten. Diese werden in einem breiteren Management-Kontext mit dem gesamten ART geklärt. Die Risiken werden nacheinander besprochen und mit Ehrlichkeit und Transparenz angegangen und dann in eine der folgenden Kategorien eingeordnet.
Vertrauensabstimmung - Sobald die Programmrisiken adressiert wurden, stimmen die Teams über ihr Vertrauen in die Erfüllung der PI-Objectives ab.
Die Agenda der zwei Tage
Tag 1
- 08:00-09:00 Business Context
- 09:00-10:30 Produkt / Solution Vision
- 10:30-11:30 Architektur Vision & Entwicklungspraktiken
- 11:30-13:00 Planungskontext und Mittag
- 13:00-16:00 Team Breakouts
- 16:00-17:00 Draft Plan
- 17:00-18:00 Management Review & Problemlösung
Tag 2
- 08:00-09:00 Planungsanpassungen
- 09:00-11:00 Team Breakouts
- 11:00-13:00 Finale Pläne und Lunch
- 13:00-14:00 Programm Risiken
- 14:00-14:15 Confidence Vote
- 14:15-??:?? Plan Rework
- ??:??-??:?? Planning Retrospective & Nächste Schritte
Ich lasse den Zeitplan jetzt einfach mal kommentarlos stehen und jeder kann und soll sich diesen Plan ansehen und für sich reflektieren, inwieweit das Sinn macht und welche Lücken und Fragen zur eigenen Organisation entstehen.
Ergebnisse
Wenn du eine PI-Planning durchgeführt hast, dann solltest du eine gewisse Klarheit bekommen haben:
PI-Objectives - das sind im Grunde ein Set von SMARTen Zielen, die die Teams mit den Business Ownern reflektiert und nach Geschäftswert bewertet haben.
Ein Program Board - dieses zeigt dir die Abhängigkeiten zwischen den Teams, die Sichtbarkeit und Hervorhebung der wichtigen Termine zur Lieferung sowie Meilensteine.
Fazit und Ausblick
Kurzer Check: Übersicht und Reflexion der zwei Tage
Wenn du jetzt noch kein SAFe kennst und von einem Einheiten-Ansatz kommst, dann wirst du dich hier sehr erschrecken. Was sofort auffällt ist die schiere Anzahl an Rollen, die eher an eine klassische Organisation, als an ein agiles (anderes) Verhalten und arbeiten erinnert. Ebenso kannst du hier auch gut das Ebenen-Muster erkennen.
Wenn wir hier reine Scrum-Skalierungsansätze vergleichen (was SAFe nicht ist, insofern hinkt der Vergleich etwas), dann stellen wir fest, dass aus der einen Rolle “Product Owner” (siehe Scrum, LeSS und Nexus) und selbstverantwortlichen Teams (die zum Beispiel diese zwei Tage selbstverantwortlich gestalten würden) ein starker Formalismus entstanden ist. Schau dir dazu auch noch gerne die konkrete Agenda an. Ebenso siehst du hier viele Rollen, die unterschiedliche Aufgaben an diesen zwei Tagen haben.
Learnings, Impulse & Eindrücke
Persönlich finde ich 2 Tage für etwas Zeit zu haben, sehr gut und oft notwendig. Teamfindungsworkshop, Refinements, Planungen - je nach Rahmenbedingungen scheint zwei Tage ein Rahmen zu sein, in dem sehr viel möglich ist.
Ganze zwei Tage benötigt es oft aber auch nur aus einem entscheidenen Grund: die Zeit zwischen zwei Events, bis man sich wieder trifft. Klar ist: Wer sich nach einer Woche erneut trifft, hat bei weitem nicht so viele Änderungen, die alle erneut synchronisiert werden müssen, wie Menschen, die sich nach drei Monaten weder treffen.
So sehr ich auch das
Einheiten Muster mag, so sehr sehe ich auch viele Unternehmen, die einfach auf dem
Quartalsrhythmus gerne und gut arbeiten können. Hier greifen viele Unternehmen gerne zu so einer
größeren Planung. Und das scheint mir aktuell auch wieder ein Muster zu sein, bei denen dann Menschen auf einen
strukturierten Ansatz zurückgreifen.
In größeren digitalen Planungssession (egal ob SAFe oder nicht) habe ich schon mehrfach wahrgenommen, dass Personen sagen “wow, wir sind durch diesen harten Takt der Termine an diesem Tag schneller und organisierter.
Der ewige Kampf um “ist das agile oder nicht, was SAFe macht” ist für mich oft zu kurz gedacht. Wer mit einem “agilen Ansatz” Scrum meint, wird die Frage natürlich schnell verneinen können. Wer sich bestimmte Unternehmen aber ansieht, stellt fest, dass SAFe durchaus ein erster Schritt in einer Veränderung von “weg von dem alten Vorgehen, hin zu einem neuen” sein kann. Ich plädiere dabei bei solchen Fragen immer zu reflektieren und konkrete Fragestellungen durchzuspielen.
