Der ultimative Leitfaden für das PI Planning - 2022 SAFe Edition

Wenn Sie in Ihrem Unternehmen gerade mit der Skalierung agiler Teams beginnen, genügt meist der bloße Gedanke mehrere Teams in einem Raum zusammenzubringen, um Angstschweiß auszulösen. Oder vielleicht betreiben Sie bereits seit einer Weile PI-Planning-Runden – aber es läuft nicht ganz reibungslos und Sie wissen nicht so recht, wie Sie sich verbessern können. Der folgende ultimative Leitfaden zum PI Planning hilft Ihnen, das gesamte Prozedere ab sofort effektiv und stressfrei zu meistern.

Unsere Partner von Easy Agile haben diesen umfassenden Leitfaden zum Thema PI Planning 2022 SAFe Edition zusammengestellt (hier im englischen Original). Ziel ist es, noch immer verbreitete Mythen zum Thema aufzuklären und Methoden zum Abhalten erfolgreicher und effektiver SAFe PI Planning Sessions vorzustellen. Außerdem beantworten wir eine Reihe von häufig gestellten Fragen zum PI Planning (auch in Zeiten des Corona-Virus) und geben Ihnen Erklärungen zu den wichtigsten Fachbegriffen an die Hand.

Und ja, dieser Guide ist sehr umfangreich. Scheuen Sie sich also nicht, im Inhaltsverzeichnis direkt zu den für Sie relevantesten Themen zu springen.

Genderhinweis: Allein aus Gründen der besseren Lesbarkeit wird auf die gleichzeitige Verwendung männlicher und weiblicher Sprachformen verzichtet.

Der PI Planning Guide beantwortet folgende Leitfragen:

• Was ist eigentlich ein PI Planning?
• Tipps an verteilte Teams und Remote PI Planning
• Warum ein PI Planning?
• Was ist das Ziel eines PI Plannings?
• Was sollte in die PI Planning Agenda aufgenommen werden?
• Was wird im ersten Teil des PI Planning Meetings erreicht?
• Warum wird am Ende des PI Planning Meetings ein Confidence Voting abgehalten?
• Wann findet ein PI Planning statt?
• Was ist ein Pre-PI Planning Event und wann ist ein solches notwendig?
• Was hat SAFe mit PI Planning zu tun?
• Worum handelt es sich beim PI Planning in Scrum?
• Was ist der Unterschied zwischen einer PI Roadmap und einer Solution Roadmap?
• Was ist ein Programm?
• Was ist ein Programm-Board?
• Wer sollte am PI Planning beteiligt sein?
• Wie bereitet man sich auf ein PI Planning vor?
• Was macht man nach dem PI Planning?
• Was ist Post PI Planning?
• Häufige Fehler und Herausforderungen
• Einsatz von Jira im PI Planning

Was ist eigentlich ein PI Planning?

Die wesentlichen Elemente eines PI Plannings sind:

• Zwei ganztägige Events, die alle acht bis zwölf Wochen stattfinden (je nach Länge Ihrer Increments aka Planungsabschnitte)
• Produktmanager arbeiten daran, die geplanten Features für das Increment im Voraus zu priorisieren
• Entwicklungsteams sind für die Planung und Bewertung der User Story zuständig
• Engineers und UX-Teams validieren die Planung
• Ziel ist es, die Teams auf die Mission und aufeinander abzustimmen
• Jeder nimmt (sofern möglich) persönlich teil
• Technologie wird (falls notwendig) verwendet, um verteilten Teams die Teilnahme zu ermöglichen

Wenn Sie SAFe zum ersten Mal anwenden, beginnen Sie vermutlich mit dem PI Planning. Das liegt daran, dass dieser Planungsansatz die Grundlage für das Scaled Agile Framework™ bildet.

Ganz gleich, ob Sie alle fünf Ebenen oder nur die wesentlichen Elemente von SAFe übernehmen: Die Grundlage auf Ihrem Weg zum agilen Unternehmen und der Treiber von allem ist das PI Planning.

Tipps an verteilte Teams und Remote PI Planning

Falls Ihre Teams nicht bei jedem vierteljährlichen PI Planning Meeting persönlich anwesend sein können, müssen Sie sich mit der Umsetzung eines Remote-PI Planning Events befassen. Keine Sorge – auch das ist problemlos machbar und bietet sich ideal für Unternehmen mit verteilten Teams oder flexiblen Arbeitsregelungen an. Außerdem sind solche Meetings viel günstiger als die Teilnehmer alle paar Monate einfliegen zu lassen.

Wenn Sie über die richtigen Tools und Technologien verfügen, können Sie PI Planning Events veranstalten, an denen jeder teilnehmen kann: Egal, ob er sich im selben Raum oder auf der anderen Seite der Welt befindet.

Hier einige Tipps, die Ihnen dabei helfen werden:

Nutzen Sie die Cloud

Verwenden Sie gemeinsam nutzbare Online-Planungstools, damit Ihr Team so schnell wie möglich auf Informationen zugreifen und mit diesen interagieren kann – im Idealfall sogar in Echtzeit. Indem Sie sicherstellen, dass jeder Teilnehmer die Informationen sofort einsehen kann, können Abhängigkeiten leichter identifiziert und das unnötige Speichern der Infos an zehn oder mehr Orten vermieden werden.

Finden Sie sich vor Ort zusammen

Versuchen Sie, dass sich alle Beteiligten soweit möglich vor Ort versammeln und gemeinsam einwählen (anstatt jeweils von ihren eigenen Locations aus remote). Sie könnten etwa im Hauptsitz die Führungsgruppe sowie die Teams aus der Nähe versammeln und dann Mitarbeiter an anderen Orten zu ihrem nächstgelegenen Remote-Standort einfliegen lassen. Auf diese Weise profitiert jeder vom Aspekt der persönlichen Zusammenarbeit.

Übertragen Sie das Event als Livestream

Persönliche Zusammenarbeit ist natürlich stets vorzuziehen, doch wenn diese nicht möglich ist, sollten Sie auf einen Audio- und Video-Livestream des Events und der Teilnehmer zurückgreifen. Das bedeutet, dass Sie alle verteilten oder Remote-Teams davon überzeugen müssen, während des Events ihre Kameras und Mikrofone zu benutzen. Es ist zwar nicht das Selbe, wie alle Teilnehmer in einem Raum vor Ort zu haben, aber schon ziemlich nah dran.

Zeichnen Sie es auf

Im Idealfall nimmt jeder live am PI Planning teil. Allerdings kann es natürlich vorkommen, dass Teams über mehrere Zeitzonen verteilt sind oder bestimmte Teilnehmer aufgrund von Krankheit oder anderen unvorhergesehenen Gründen nicht präsent sein können – es bietet sich daher an, das Event auch aufzuzeichnen. Davon profitieren auch Teammitglieder, die selbst am Meeting teilgenommen haben, aber z. B. ihr Gedächtnis auffrischen möchten.

Passen Sie sich an

Einige Teams werden die standardmäßige PI Planning Agenda abändern, damit diese mit mehreren Zeitzonen kompatibel ist. Das kann dazu führen, dass das Event für manche früher bzw. später beginnt oder sogar über drei anstatt zwei Tage verteilt stattfindet.

Legen Sie die Regeln fest

Häufig kommt es bei verteilten Teams, die sich remote per Video und Audio einwählen, zu Störungen und Hintergrundgeräuschen. Kommunizieren Sie vor der ersten Session, wann Teams sprechen dürfen und wann sie ihren Ton stummschalten müssen. Auf diese Weise stellen Sie sicher, dass jeder teilnehmen kann und Ihre Teams nicht abgelenkt werden.

Warum ein PI Planning?

Ein PI Planning ist für große und zudem agile Unternehmen von unschätzbarem Wert. Sehen wir uns einige Zahlen an, um uns die Bedeutung vor Augen zu führen. Nehmen wir als Beispiel etwa Organisationen mit 200 bis 300 Teams und 10.000 Entwicklern: In der Vergangenheit hatten diese Teams meist nie Kontakt miteinander (zumindest nicht bis ein größeres Problem auftrat, das die Kommunikation untereinander zwingend notwendig machte).

Früher fand die Abstimmung auf Ebene der Führungsteams statt. Dazwischen gab es mehrere Managementebenen, welche die Informationen kaskadenartig nach unten weiter gaben. Die Mitarbeitenden in den Teams haben jedoch meist nicht direkt miteinander gesprochen. Es gab einen ständigen Kampf um Ressourcen, Budget und Möglichkeiten, an den attraktivsten Projekten zu arbeiten. Apropos Projekte – hier kam es nicht selten zu Konflikten: Ein Team veröffentlichte etwas und plötzlich funktionierte aufgrund dessen etwas im Projekt eines anderen Teams nicht mehr.

Beim PI Planning werden die Teams dieser wirklich großen Unternehmen erstmals in einem Raum oder im selben Call versammelt und können sich untereinander austauschen. So haben sie Gelegenheit, die so wichtigen Gespräche darüber zu führen, wer woran arbeitet.

Das ist ziemlich wichtig, denn:

• Wenn Sie etwas an einem System oder einem Code-Repository ändern, müssen Sie wissen, wie sich dies auf ein anderes Team auswirkt.
• Es kann sein, dass Sie zuerst etwas erledigen müssen, bevor ein anderes Team an seinem Feature arbeiten kann (und umgekehrt).

Alles sehr gute Gründe für ein PI Planning. Doch betrachten wir auch das große Ganze.

Was ist das Ziel eines PI Plannings?

Das PI Planning ist ein wesentlicher Bestandteil des Scaled Agile Frameworks™, welches großen Unternehmen mit mehreren Teams Agilität verleihen soll. SAFe PI Planning unterstützt Teams im Agile Release Train bei der Synchronisierung, der Kollaboration und der Abstimmung von Workflows, Zielen, Releases und mehr.

Auf der anderen Seite haben Teams ohne ein PI Planning keine strukturierte Kommunikationsmöglichkeit. Eventuell wissen sie daher nicht, woran die anderen Teams gerade arbeiten. Das kann eine Menge Probleme verursachen. Zum Beispiel könnten zwei Teams an verschiedenen Features arbeiten, ohne zu erkennen, dass eine Abhängigkeit besteht – welche im schlimmsten Fall die Release verzögert oder eine wesentliche Überarbeitung des Codes erforderlich macht.

Ziel eines PI Plannings ist es also, sämtliche Teams strategisch auszurichten und eine teamübergreifende Zusammenarbeit zu ermöglichen, um all diese potenziellen Probleme zu vermeiden.

Nachdem wir nun das „Warum“ abgedeckt haben, wollen wir etwas tiefer in das „Was“ eintauchen. Am besten kann man sich ein Bild über ein PI Planning machen, indem man einen Blick auf die Agenda wirft.

Was sollte in die PI Planning Agenda aufgenommen werden?

Die Standardvorlage einer PI Planning Agenda, wie sie auf der SAFe-Website zu finden ist:

Tag 1
08:00–09:00 Uhr Businesskontext
09:00–10:30 Uhr Produkt-/Lösungsvision
10:30–11:30 Uhr Architekturvision und Entwicklungspraktiken
11:30–13:00 Uhr Planungskontext und Mittagessen
13:00–16:00 Uhr Team-Breakouts
16:00–17:00 Uhr Review des Planentwurfs
17:00–18:00 Uhr Managementreview und Problemlösung

Tag 2
08:00–09:00 Uhr Planung von Anpassungen
09:00–11:00 Uhr Team-Breakouts
11:00–13:00 Uhr Abschließende Planreview und Mittagessen
13:00–14:00 Uhr Programmrisiken
14:00–14:15 Uhr Confidence Vote
ab 14:15 Uhr Nachbearbeitung des Plans (falls erforderlich)
Wenn bereit: Planungsretrospektive und Zukunftsaussichten

Quelle der Agendavorlage: Scaled Agile Framework™

Vielleicht passt diese Agenda für Sie bereits perfekt, oder Sie möchten sie den Bedürfnissen Ihres Teams entsprechend anpassen. Beides ist selbstverständlich in Ordnung: Verteilte Teams, sehr große Agile Release Trains und andere Faktoren haben gegebenenfalls zur Folge, dass Sie mit der Planung etwas kreativer werden müssen. Es kann sein, dass einige Sessions mehr Zeit erfordern, während andere gekürzt werden können. Falls es sich um Ihr erstes PI Planning Event handelt, probieren Sie einfach die Standardagenda aus, holen Sie sich Feedback bei Ihren Teams ein und experimentieren Sie beim nächsten Mal mit verschiedenen Formaten.

Betrachten wir nun die einzelnen Punkte der Agenda etwas genauer – insbesondere die ersten Stunden einer PI Planning Session an Tag 1.

Was wird im ersten Teil des PI Planning Meetings erreicht?

Tag 1 beginnt normalerweise mit der Präsentation eines Senior Executives oder des Business Owners. Die Agenda sieht eine Stunde für die Besprechung des aktuellen Geschäftsstands vor. Im Rahmen dessen werden spezifische Kundenbedürfnisse aufgezeigt. Daneben wird erläutert, wie die aktuellen Produkte diese abdecken, und gegebenenfalls werden potenzielle Lücken aufgedeckt.

Danach stellt das Produktmanagementteam die aktuelle Vision für das Produkt oder die Lösung vor. Es bespricht alle Änderungen, die seit der letzten PI Planning Session (in der Regel etwa drei Monate zuvor) eingetreten sind. Es folgt ein Ausblick auf die Zukunft, mitunter auf die Meilensteine und die nächsten zehn Features. Diese Session sollte etwa 1,5 Stunden dauern. Im ersten Teil des PI Planning Meetings geht es allein um das große Ganze. So wird ein wichtiger Kontext für die Planung geschaffen, die im Anschluss folgen muss.

Springen wir nun etwas nach vorn und betrachten wir einen wichtigen Schritt am Ende des Meetings.

Warum wird am Ende des PI Planning Meetings ein Confidence Voting abgehalten?

Das Confidence Voting ist ein scheinbar kleiner, aber doch sehr wichtiger Teil des PI Planning Meetings. Das Confidence Voting wird am Ende beinahe jedes PI Planning Events abgehalten. Der Release Train Engineer fragt: „Werden wir die Ziele erreichen?“

Jeder im Raum muss per Handzeichen (und mit seinen Fingern) abstimmen. Beträgt die durchschnittliche Stimmzahl im Raum mindestens drei Finger, so erhält der Plan grünes Licht. Sind es weniger, muss er überarbeitet werden (bis ein höheres Vertrauenslevel erreicht wird). Wer nur mit einem oder zwei Fingern abstimmt, erhält die Gelegenheit, eine Begründung für diese Entscheidung mitzuteilen.

Beim Confidence Vote geht es darum, sicherzustellen, dass die Teilnehmer sich einig sind, den Plan in seiner aktuellen Form innerhalb des vorgegebenen Zeitrahmens umsetzen zu können.

Apropos Timing: Sprechen wir darüber, wie und wo das PI Planning in Ihren Unternehmenskalender passt.

Wann findet ein PI Planning statt?

Viele Unternehmen sind der Ansicht, dass acht bis zwölf Wochen (was vier bis sechs zweiwöchige Iterationen ergibt) die richtige Dauer für einen Planungsabschnitt sind. Andere Unternehmen führen hingegen vierteljährlich ein PI Planning Meeting durch, beispielsweise:

• Q1 PI Planning: Dezember
• Q2 PI Planning: März
• Q3 PI Planning: Juni
• Q4 PI Planning: September

Zeitpunkt und Häufigkeit hängen davon ab, wie lange die einzelnen Program Increments dauern sollen (und müssen ggf. mit Feiertagen in Einklang gebracht werden). Der Vorteil von PI Planning Events ist, dass sie regelmäßig nach einem festen Zeitplan stattfinden. Das bedeutet, dass man sie weit im Voraus planen kann – was wiederum dazu führt, dass die Teams und Business Owner ausreichend Zeit haben, um ihre Anwesenheit sicherzustellen. Entsprechend sind die Vorbereitungen für das PI Planning ebenso entscheidend wie das Event selbst.

Was ist ein Pre-PI Planning Event und wann ist es notwendig?

Die Vorbereitung in Form eines pre-planning Events – zusätzlich zum PI Planning – hat einen wichtigen Hintergrund: Es soll sicherstellen, dass der ART im Rahmen des weiteren Solution Train ausgerichtet ist, bevor ein PI Planning durchgeführt wird. Es geht darum, sich mit den anderen ARTs abzustimmen, um sicherzustellen, dass das Projekt und das Unternehmen sich gemeinsam auf eine Ausrichtung fokussieren.

Ist ein Pre-PI Planning für mich sinnvoll?

Sie sollten ein Pre-PI Planning Event organisieren, wenn Sie auf Ebene der Large Solution, des Portfolios oder von Full SAFe arbeiten. Essential SAFe ist eher rudimentär ausgerichtet und verfügt über keinen Solution Train. Wenn Sie also auf dieser Ebene agieren, ist kein Pre-PI Planning erforderlich.

Normalerweise finden sich die Schlüsselpersonen aus dem Solution Train mit den Vertretern der Agile Release Trains und den relevanten Suppliern zusammen. Hier einige Personen, die Sie auf dem Planning-Event antreffen werden:

• Solution Train Engineer
• Solution Management
• Solution Architect/Engineering
• Solution System Team
• Release Train Engineers
• Produktmanagement
• System Architects/Engineers
• Kunden

Diese Personen werden gemeinsam die zentralen Potenziale des Solution Backlog, des Solution Intent, der Vision und der Solution Roadmap näher betrachten. Das Ganze ähnelt dem PI Planning sehr, findet aber auf einer höheren Ebene statt und deckt die gesamte Lösung und nicht nur den individuellen ART ab.

Das Event beginnt damit, dass jeder ART sein vorheriges Program Increment und seine Leistungen zusammenfasst, um einen Kontext zu schaffen. Anschließend informiert ein Senior Executive die Teilnehmer über die derzeitige Situation, bevor das Solution Management die aktuelle Lösungsvision und etwaige Änderungen gegenüber den vorherigen Mitteilungen diskutiert. Zu den weiteren Aspekten, die im Rahmen des Events oft diskutiert oder finalisiert werden, zählen mitunter:

• Roadmaps
• Meilensteine
• Solution Backlogs
• künftige PI-Features aus dem Program Backlog

Kehren wir nun zum regulären PI Planning zurück: Es ist an der Zeit, einige bereits angesprochene zentrale Begriffe genauer zu definieren.

Was hat SAFe mit PI Planning zu tun?

Wie bereits erwähnt steht die Abkürzung SAFe für „Scaled Agile Framework™“.

SAFe legt fest, was auf jeder Ebene des Unternehmens geschehen muss, um sicherzustellen, dass die Agile-Skalierung zum Erfolg wird. Das Framework geht weit über die Teamebene hinaus und schließt jeden Stakeholder ein.

Die Idee dahinter ist, dass Unternehmen, die auf SAFe setzen, von einer besseren Abstimmung zwischen den Teams und von einer optimierten Sichtbarkeit der Arbeit profitieren - was sich wiederum in besseren vorhersehbaren Geschäftsergebnissen niederschlägt. Dieser Aspekt gewinnt zunehmend an Bedeutung, da sich die Rahmenbedingungen für Unternehmen kontinuierlich ändern und Kunden mehr Features in kürzerer Zeit erwarten. Die traditionellen Wasserfallmodelle sind hierfür nicht ausreichend, weil sie langsam und ineffizient sind.

Große Unternehmen (die oft tausende Entwickler beschäftigen) können mit der Innovationskraft kleinerer, flexiblerer Start-ups häufig nicht mithalten. Sie verfügen nicht nur über umfassendere Teams: Oft müssen bei großen Unternehmen auch deutlich strengere Kontroll- und Compliance-Vorschriften eingehalten werden, was die Geschwindigkeit ebenfalls dämpft. Es kann drei bis vier Jahre dauern, bis diese Firmen mit ihren komplexen Strukturen ein neues Feature auf den Markt bringen – das entspricht keineswegs den Kundenwünschen von heute. Außerdem haben sie oft Schwierigkeiten, ihre (zahlreichen!) Entwicklerteams zu verwalten und zu organisieren, was auch ein Hindernis für den Start von Projekten zur rechten Zeit darstellt.

Diese Unternehmen müssen Änderungen vornehmen, um Abläufe zu beschleunigen, ihre Ressourcen optimal zu nutzen und Budgetexplosionen einzuschränken. Sie suchen nach neuen Wegen, Menschen im Rahmen von Projekten zu organisieren und effektivere Arbeitsweisen einzuführen. Tun sie das nicht, laufen sie Gefahr, ihre Wettbewerbsfähigkeit zu verlieren.

SAFe stellt eine Möglichkeit für diese Unternehmen (welche sonst in ihren alten Prozessen feststecken würden) dar, sich in eine agilere Richtung zu bewegen.

Moment mal: Was hat das mit PI Planning zu tun?

PI Planning ist ein zentrales Element von SAFe. Es ist ein Prozess, der Vertreter aus allen Teams zusammenbringt und bei zahlreichen Abläufen unterstützt: die Zusammenarbeit wird gefördert; die Top-Features, an denen zeitnah gearbeitet werden soll, können leichter abgesprochen; Abhängigkeiten identifiziert und ein Plan für das nächste Program Increment erstellt werden. Das führt im Endergebnis zu einer größeren Sichtbarkeit aller Teams, zu schnelleren Anpassungen sowie einer besseren Zusammenarbeit – ein Miteinander statt ein Gegeneinander wird geschaffen. Von diesem Punkt aus können Unternehmen ihre Prozesse beschleunigen, effizienter arbeiten, mit neueren sowie flexibleren Wettbewerbern konkurrieren und weiterhin am Markt bestehen.

SAFe und PI Planning sind starke Instrumente, Organisationen hinsichtlich agiler Arbeitsweisen zu befähigen.

Worum handelt es sich beim PI Planning in Scrum?

Sie können PI Planning auch außerhalb von SAFe als Teil eines simplen Scrum-Ansatzes verwenden. Das Scrum-Framework-Diagramm zeigt, wann und wie Scrum-Teams ein PI Planning implementieren können.

Falls mehrere Scrum-Teams besser zusammenarbeiten möchten (aber nicht im Rahmen von SAFe agieren), bietet sich eine Variante des PI Plannings an.

Zum Beispiel könnten diese Scrum-Teams:

• sich alle zehn Wochen treffen und die geplanten Features besprechen.
• Produktmanager dazu bringen, Backlogs zu kombinieren und gemeinsam Prioritäten zu setzen.
• die Ressourcen je nach Bedarf über die Teams hinweg aufteilen.
• Abhängigkeiten identifizieren und gemeinsame Releases koordinieren.

Die gute Nachricht ist, dass es keinen Universalansatz für ein PI Planning gibt. Überlegen Sie sich also selbst, wie Sie die Ideen und Prinzipien übernehmen und für Ihr Unternehmen nutzen können.

Apropos PI-Planning-Ideen: Einer der nützlichsten Aspekte des PI Plannings ist wohl die Roadmap, die ebenfalls auf Grundlage der während des PI Plannings gewonnenen Erkenntnisse aktualisiert wird. Hier eine Frage, die häufiger gestellt wird:

Was ist der Unterschied zwischen einer PI Roadmap und einer Solution Roadmap?

Es gibt verschiedene Arten von Roadmaps im Rahmen von SAFe. Daher ist es wichtig, deren Unterschiede und Funktionen zu verstehen.

Die PI Roadmap wird vor dem PI Planning erstellt und nach Abschluss des Events vom Produktmanagement überprüft sowie aktualisiert. Sie umfasst in der Regel drei Program Increments:

1. das aktuelle Increment (festgelegte Arbeit)
2. das nächste prognostizierte Increment (geplante Arbeit auf Grundlage der prognostizierten Ziele)
3. das darauffolgende Increment (weitere geplante Arbeit auf Grundlage der prognostizierten Ziele)

Wenn Sie vierteljährlich ein PI Planning Meeting durchführen, umreißt das die Arbeit für etwa neun Monate. Das zweite und dritte Increment Ihrer PI Roadmap wird sich wahrscheinlich abhängig von Ihren Prioritäten ändern. Doch beide sind dennoch ein wichtiger Teil der Roadmap, da sie in Ausblick stellen, in welche Richtung sich das Produkt entwickeln wird.

Worum geht es also bei der Solution Roadmap?

Die Solution Roadmap ist ein Tool zur längerfristigen Prognose und Planung eines bestimmten Produkts oder einer bestimmten Dienstleistung. Sie deckt in der Regel mehrere Jahre ab, wobei für das erste Jahr spezifischere (z. B. vierteljährliche Features und Potenziale) und für das zweite Jahr und darüber hinaus allgemeinere Informationen (z. B. Ziele) zur Verfügung stehen.

Jetzt, wo wir Roadmaps, Scrum und SAFe behandelt haben, sollten wir uns eine weitere Definition ansehen, die Ihnen dabei hilft, PI Planning in das Gesamtbild von Agile und SAFe einzuordnen.

Was ist ein Program?

Bei einem Programm werden mehrere kleinere agile Teams zu einer größeren Gruppe zusammengeführt. Dies wird oft als „Team of Teams“-Ebene bezeichnet. Wenn jemand von „Team of Teams” oder „Scaled Agile“ spricht, meint er damit, dass Agile über ein einzelnes Team hinausgeht und man weitere Teams zur Mitarbeit einlädt.

Nehmen wir an, vier Teams arbeiten an einer NASA-Raumschiffmission für die Reise zum Mars. Die NASA beschließt, zu testen, ob der Agile-Ansatz die Arbeit dieser Teams verbessern würde. Daher wird zunächst das „Sauerstoffteam” vom traditionellen Wasserfallprojektmanagement auf Agile-Prinzipien umgestellt.

• Startteam
• Lebensmittelteam
• Sauerstoffteam – (Agile)
• Landungsteam

Nach ein paar Monaten ist die NASA der Ansicht, dass die Arbeitsweise des Sauerstoffteams wirklich gut funktioniert. Daher stellen die drei anderen Teams ebenfalls auf Agile um.

• Startteam – Agile!
• Lebensmittelteam – Agile!
• Sauerstoffteam – Agile!
• Landungsteam – Agile!

Jedes dieser vier Teams organisiert sich selbst und ist damit für seine eigene Arbeit verantwortlich. Da diese Teams nun aber alle auf dieselbe Weise arbeiten, können sie zu einem Programm zusammengefasst werden.

Einfach ausgedrückt ist ein Programm also eine Gruppe von Agile-Teams. Sobald Sie die Business Owner, das Produktmanagementteam, die System Architects bzw. -Engineers und den Release Train Engineer hinzuziehen, sind alle Rollen abgedeckt, die für eine kontinuierliche System- oder Lösungsbereitstellung über den Agile Release Train erforderlich sind.

Behandeln wir nun eine letzte Definition.

Was ist ein Program Board?

Program Boards stellen einen wichtigen Teil von SAFe und des PI Plannings dar.

SAFe Program Boards müssen allerdings nicht unbedingt physischer Natur sein. Digitale Program Boards wie Easy Agile Programs, das sich direkt mit Jira integrieren lässt, bieten zahlreiche Vorteile. Gegen Ende dieses Leitfadens behandeln wir, wie Sie Jira für PI Planning einsetzen können.

Sprechen wir aber zuerst darüber, wer am PI Planning beteiligt ist.

Wer sollte am PI Planning beteiligt sein?

Es gibt fünf Schlüsselrollen, die am PI Planning mitwirken:

• Release Train Engineers
• Produktmanager
• Product Owner
• Scrum Master
• Entwickler

Sehen wir uns genauer an, wofür jede dieser Rollen während des Events verantwortlich ist.

Release Train Engineer

Der Release Train Engineer ist ein Servant Leader und Coach für den ART. Seine Rolle besteht hauptsächlich aus der Planung und Umsetzung des PI Planning Events. Das heißt, Release Train Engineers helfen bei:

• der Erstellung und Kommunikation der Jahresplanung
• der Vorbereitung sämtlicher Aspekte des PI Plannings (einschließlich der Pre- und Post-PI Planning Meetings)
• der Verwaltung der Risiken und Abhängigkeiten
• der Erstellung von Program PI Objectives aus Team PI Objectives und der Veröffentlichung derselben
• der Nachverfolgung des Fortschritts in Richtung der erwarteten Ziele
• der Ausrichtung von Strategie und Ausführung
• der Ermöglichung von Systemdemos

Als „Veranstalter“ des zweitägigen Events stellt der Release Train Engineer den Planungsprozess sowie die erwarteten Ergebnisse vor und ermöglicht die Management-Review, die Problem-Solving-Session sowie die Retrospektive.

Produktmanager

Die Aufgabe eines Produktmanagers besteht darin, die Bedürfnisse der Kunden zu verstehen und Lösungen zu validieren. Gleichzeitig soll er Portfolioarbeit nachvollziehen und unterstützen.

Welche Rolle spielt ein Produktmanager nun beim PI Planning?

Er präsentiert die Vision des Programms (d. h. die zehn wichtigsten anstehenden Features) sowie alle kommenden Meilensteine. Er überprüft den Planentwurf und legt sämtliche Änderungen an der Planung selbst sowie an deren Umfang auf Grundlage der Management-Review sowie der Problem-Solving-Session dar. Auf diese Weise kann der Produktmanager den Arbeitsfluss steuern und Prioritäten setzen. Nach Abschluss des PI Planning Events verwendet er die Program Objectives des Release Train Engineers, um die Roadmap zu aktualisieren.

Es sollte darüber hinaus erwähnt werden, dass der Produktmanager auch am Pre- und Post-PI-Planning beteiligt ist. Vor dem eigentlichen PI Planning findet ein Pre-PI Planning Meeting statt, bei dem der Produktmanager und andere ART-Vertreter, die Teil desselben Solution Train sind, die Beiträge, Ziele und Meilensteine für ihre nächsten PI Planning Events diskutieren und definieren.

Im Rahmen des Post-PI Planning Meetings treffen sich die Vertreter des ART erneut, um den Verlauf ihrer PI Planning Events zu diskutieren und die Ergebnisse in den Solution PI Objectives zusammenzufassen. Produktmanager spielen eine zentrale Rolle bei der Kommunikation der Ergebnisse und der Erstellung der Ziele.

Product Owner

Die Product Owner sind für die Wartung und Priorisierung des Team Backlog sowie für Iteration Planning verantwortlich. Sie haben die Autorität, während der PI Planning Team Breakout Sessions Entscheidungen auf der Ebene der User Story zu treffen.

Product Owner unterstützen das Team bei der Definition der Stories, der Einschätzung und der Sequenzierung sowie bei der Ausarbeitung der PI Objectives des Teams und der Teilnahme am Team Confidence Voting. Sie sind auch dafür verantwortlich, dem Team Visionen und Ziele aus den oberen Managementebenen zu vermitteln:

• Berichterstattung über wichtige Leistungskennzahlen
• Auswertung des Fortschritts
• Kommunikation des Status an die Stakeholder

Scrum Master

Scrum Master sind Servant Leader des Product Owner und des Entwicklerteams, d. h. dass sie neben der Verwaltung und Leitung von Prozessen dem Team auch praktisch dabei helfen, Aufgaben zu erledigen.

Sie wirken an der Event-Vorbereitung (einschließlich PI Planning) mit und bereiten Systemdemos vor. Sie helfen dem Team bei der Einschätzung der Iterationskapazität, bei der Festlegung der Team PI Objectives sowie bei der Verwaltung des Zeitrahmens, der Abhängigkeiten und der Unklarheiten während der Team-Breakout-Sessions. Die Scrum Master nehmen auch an Confidence Votings teil, um das Team dabei zu unterstützen, einen Konsens zu erreichen.

Entwickler

Entwickler sind für die Erforschung, den Entwurf, die Implementierung, das Testen, die Wartung und die Verwaltung von Softwaresystemen verantwortlich.

Während des PI Plannings nehmen sie an Breakout-Sessions teil, um (gemeinsam mit ihrem Product Owner) User Stories sowie Akzeptanzkriterien zu erstellen und zu verfeinern. Sie passen darüber hinaus auch den Arbeitsplan an. Die Entwickler tragen zur Identifizierung von Risiken sowie Abhängigkeiten bei und unterstützen das Team bei der Ausarbeitung und Finalisierung der Team PI Objectives, bevor sie am Team Confidence Voting teilnehmen.

Nun kennen Sie die wichtigsten Definitionen. Außerdem wissen Sie auch, was während eines PI Planning Events unternommen werden muss und wer dabei nicht fehlen darf.

Wie bereitet man sich auf ein PI Planning vor?

„By failing to prepare, you are preparing to fail.“ – Benjamin Franklin

Erfolgreiches PI Planning erfordert entsprechende Vorbereitungen, die Sie nicht unter den Tisch fallen lassen sollten! Jedes PI Planning Event fußt auf einer durchdachten Planung. Nur so können Ihr Unternehmen und alle Teilnehmer das Beste daraus machen und die angestrebten Ziele erreichen.

Wie sieht diese Vorbereitung also konkret aus?

Die Teilnehmer selbst (sowie die wichtigsten Stakeholder und die Business Owner) müssen Schlüsselrollen zuweisen, die Ausrichtung an der Strategie sicherstellen und dafür sorgen, dass alle den Planungsprozess richtig verstehen.

Alle Vortragenden müssen einschlägige Inhalte für ihre Präsentationen vorbereiten.

Außerdem müssen Sie dafür sorgen, dass Ihre Räumlichkeit für das Event gewappnet ist – insbesondere, wenn Sie hunderte Teilnehmer erwarten. Hierbei müssen die üblichen Vorbereitungen für eine Veranstaltung getroffen werden, insbesondere dem technischen Aspekt (Audio, Video, Internetverbindung) sollten Sie ein erhöhtes Maß an Aufmerksamkeit zukommen lassen, damit etwaige verteilte Teams am PI Planning Event teilnehmen können. Vergessen Sie darüber hinaus nicht, für genügend Essen zu sorgen (Planen macht hungrig).

Nun wissen wir ziemlich genau, was vor und während eines PI Planning Events geschehen muss, doch wie steht es um die Nachbereitung?

Was macht man nach dem PI Planning?

Im Anschluss an das PI Planning Meeting erstellen die Teams eine Planungsretrospektive und listen auf:

• was gut gelaufen ist (leckere Snacks),
• was nicht so gut gelaufen ist (nicht genügend Snacks) und
• was man das nächste Mal besser machen könnte (ehm, bitte lass in Zukunft auch Kekse für die anderen über).

Anschließend folgt ein Gespräch über die nächsten Schritte. Mitunter zählen hierzu:

• das Einpflegen von Kopien der Objectives, der User Stories und des Program Boards ins Projektmanagement-Tool (z. B. Jira)
• ein Blick auf die Kalender
• die Absprache der Meeting-Zeiten und -orte für Daily Standups und Iterationsplanung
• das Überprüfen der persönlichen Gegenstände und das saubere Hinterlassen des Veranstaltungsorts

Daneben findet nach einem PI Planning Event in der Regel auch ein Post PI Planning Event statt.

Was ist Post PI Planning?

Post PI Planning Events ähneln den bereits besprochenen Pre-PI Plannings. Hierunter fällt die Zusammenführung der ART-Stakeholder über alle Agile Release Trains innerhalb des Solution Train hinweg. Das soll sicherstellen, dass diese aufeinander abgestimmt sind.

Das Post PI Planning findet statt, nachdem sämtliche ARTs ihr PI Planning für das nächste Increment abgeschlossen haben. Sie stellen die Pläne vor, erklären ihre Ziele und teilen Meilensteine und erwartete Zeitpläne mit.

Wie bei PI Planning Events wird auch bei Post PI Planning ein Planning Board verwendet - das jedoch keine Features, sondern Potenziale, Abhängigkeiten und Meilensteine für jede Iteration und jeden ART aufzeigt. Mögliche Probleme und Risiken werden identifiziert, diskutiert und entweder zugeteilt, gelöst, akzeptiert oder entschärft. Ähnlich wie bei regulären PI Planning Events werden die Pläne mithilfe eines Fist-of-Five-Vertrauensvotums (auch Fist to Five genannt) geprüft, um sicherzustellen, dass sie die Solution Objectives erfüllen. Sie werden so lange überarbeitet, bis im Durchschnitt drei Finger hochgehalten werden.

Häufige Fehler und Herausforderungen

Ein PI Planning verläuft nicht immer … nun ja, nach Plan und auch das Framework als solches kann eine Herausforderung für einige Unternehmen darstellen. Nachfolgend beschreiben wir einige Fehler und Herausforderungen, die Sie im Hinterkopf behalten (und falls möglich vermeiden) sollten:

Lange, langweilige Sessions

Zu den größten Schwachpunkten des PI Planning im Rahmen der vorgeschlagenen Agenda zählen die langwierigen, anstrengenden Sessions direkt zu Beginn. Es lohnt sich eventuell, nach kreativen Möglichkeiten zu suchen, wie diese Sessions interessanter gestaltet, die Informationen zum Businesskontext in einem anderen Format präsentiert oder die veranschlagten Zeiträume verkürzt werden können. Auf diese Weise bleibt mehr Zeit für die Teamplanung und Zusammenarbeit.

Technische Probleme

Jedes Event ist anfällig für technische Pannen. Aber wenn Sie Audio- und Video-Streams an ein verteiltes Team übertragen, können derartige Störungen den Ablauf des gesamten Meetings maßgeblich beeinflussen. Es ist ratsam, alle Geräte und Verbindungen im Vorfeld sorgfältig zu testen, um das Risiko potenzieller Probleme zu minimieren.

Confidence Voting

Einige Teilnehmer tun sich mit dem Konzept des Confidence Votings schwer. Möglicherweise fühlen sie sich von den anderen Anwesenden unter Druck gesetzt, für einen Plan zu stimmen, anstatt ihre Bedenken zu äußern. Das sollten Sie beachten

Zeitbeschränkungen

Wenn ein ART aus – sagen wir mal – zwölf Teams besteht, müssen eine ganze Menge Pläne präsentiert und überprüft werden. In solchen Fällen ist es wahrscheinlich, dass die Qualität des Feedbacks schlechter ausfällt als bei einem kleineren Agile Release Train mit acht Teams.

Sich nicht auf den Prozess einlassen

Weder SAFe noch das PI Planning sind perfekt. Doch der Prozess hat sich in zahlreichen Unternehmen bewährt. Es ist wichtig, sich an das Framework zu halten und Ihr PI Planning Event gemäß den Empfehlungen durchzuführen. Halten Sie sich unbedingt an den anschließenden Prozess.

Beibehalten alter Tools

Wenn etwas nicht funktioniert, dann sollten Sie sich des Problems annehmen. Beispielsweise halten viel zu viele Teams an traditionellen SAFe Program Boards fest, obwohl diese nicht immer sinnvoll sind. Wenn die Haftnotizen ständig verloren gehen, die in Jira eingegebenen Daten ein wenig daneben zu liegen scheinen oder Sie ein verteiltes Team haben, das sich eine digitale Teilnahmemöglichkeit für Ihr PI Planning Event wünscht … dann ist es an der Zeit, auf ein digitales Program Board wie Easy Agile Programs zu wechseln. Apropos Software: Nun ist (endlich) Jira an der Reihe!

Einsatz von Jira im PI Planning

Jira ist das beliebteste Projektmanagementtool für Agile-Teams. Wenn Sie agil sind, setzen Sie es wahrscheinlich bereits auf Teamebene ein. Jira eignet sich perfekt für Einzelteams.

Wenn Sie Agile jedoch auf Skalierungsebene als Teil eines ART implementieren möchten, kann die korrekte Visualisierung der Arbeit über mehrere Teams hinweg ein Problem darstellen. Die einzige Möglichkeit, dies in der nativen App von Jira zu realisieren, ist die Erstellung eines Multi-Projekt-Boards, welches allerdings ziemlich unübersichtlich ist.

Wie passt Jira also mit SAFe und dem PI Planning zusammen?

Das PI Planning bringt diese Teams zusammen, um auf Grundlage gemeinsamer Ziele die Arbeit für das nächste Increment zu planen. Während des PI Plannings verwenden die Teams ein Program Board, um ihre Arbeit zu organisieren und Abhängigkeiten zu identifizieren. Traditionell wird dazu ein physisches Board mit Haftnotizen und einer Schnur verwendet. Nach der Session werden die Notizen und die Schnur in Jira für das gesamte Team nachgebildet. Das kann mühsam und zeitaufwändig sein und lässt oft einen Großteil des Kontexts außer Acht.

Der beste Weg, Jira für das PI Planning zu verwenden, ist der Einsatz einer App wie Easy Agile Programs, die Sie bei der Durchführung Ihrer PI Planning Sessions unterstützt. Die integrierten Features ermöglichen es Ihnen:

• ein digitales Program Board einzurichten (nie wieder Schnur und Haftnotizen!),
• teamübergreifend zu planen,
• teamübergreifende Abhängigkeiten zu visualisieren und zu verwalten,
• sich an den festgelegten Zielen für das Program Increment auszurichten,
• eine Increment Feature Roadmap zu visualisieren und
• Jira von einem Tool auf Teamebene zu einem Werkzeug für den gesamten ART zu transformieren.

Schließen Sie sich Unternehmen wie Boeing, Vodafone und Prudential Insurance an, die Jira für die PI-Planung mit Easy Agile Programs verwenden.