Der ultimative Leitfaden für das PI Planning - 2020 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 ziehen langsam in Betracht, das Handtuch zu werfen. Der folgende ultimative Leitfaden für das PI Planning (aus dem Englischen von unserem Partner Easy Agile übernommen) hilft Ihnen ab sofort dabei, das gesamte Prozedere effektiv und stressfrei zu meistern. Genderhinweis: Allein aus Gründen der besseren Lesbarkeit wird auf die gleichzeitige Verwendung männlicher und weiblicher Sprachformen verzichtet.

Um was geht es in diesem Guide?

Easy Agile hat diesen vollständigen Leitfaden für das PI Planning im Jahre 2020 zusammengestellt. Damit werden bestimmte Mythen zur Thematik aus der Welt geschafft und Methoden, wie man erfolgreiche und effektive SAFe PI Planning Sessions abhält, werden detailliert unter die Lupe genommen.

In diesem Leitfaden erfahren Sie, was PI Planning überhaupt ist, warum dieses Verfahren für Ihr Unternehmen so große Bedeutung hat, wie man damit durchstartet und vieles mehr.

Außerdem beantworten wir eine Reihe von häufig gestellten Fragen zum PI Planning, damit Sie sich sicher genug fühlen, um an einem entsprechenden Event teilnehmen zu können (und dabei die richtigen Fachbegriffe zu verwenden).

Dieser ultimative Leitfaden für das PI Planning ist sehr umfangreich, daher haben wir untenstehendes Inhaltsverzeichnis erstellt. Damit können Sie direkt zum gewünschten Kapitel springen.

Wir beschäftigen uns in diesem Guide mit folgenden Themen:

• Was ist eigentlich ein 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?
• 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?
• Tipps an verteilte Teams und Remote PI Planning
• Aufkommende Fehler und Herausforderungen
• Einsatz von Jira im PI Planning

Was ist eigentlich ein PI Planning?

Dies sind die wesentlichen Elemente eines PI Plannings:

• 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 ist ein PI Planning.

Fazit: Wenn ein agiles Team das PI Planning meistert, erleichtert dies alle Schritte im darauffolgenden Projekt-Abschnitt ganz ungemein.

Betrachten wir deshalb nun das “Warum” etwas genauer.

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 Auswirkungen vor Augen zu führen. Nehmen wir etwa Konzerne 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 unausweichlich machte.)

Früher hat die Abstimmung auf Ebene der Führungsteams stattgefunden und dazwischen gab es mehrere Managementebenen, die Informationen kaskadenartig nach unten weitergaben. Zudem haben die Mitglieder der Teams 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 – da 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 großen Unternehmen erstmals in einem Raum versammelt und können sich untereinander austauschen. So haben sie die Gelegenheit, wichtige Gespräche über die Arbeitsverteilung zu führen.

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™, welcher großen Unternehmen mit mehreren Teams Agilität verleihen soll. SAFe PI Planning unterstützt Teams im Agile Release Train (ART) 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, was eine Menge Probleme verursachen kann. Zum Beispiel könnten zwei Teams an verschiedenen Features arbeiten, ohne zu erkennen, dass eine Abhängigkeit besteht, welche im schlimmsten Fall die Veröffentlichung 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, sollten 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:

Quelle der Agendavorlage: Scaled Agile Framework™

Diese Agenda könnte bereits sehr nützlich für Sie sein, doch Sie können sie selbstverständlich auch an die Bedürfnisse Ihres Teams anpassen. Verteilte Teams, sehr große ARTs 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. Spulen wir nun etwas vor und sprechen wir über 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.

Bei der Confidence Vote geht es darum, sicherzustellen, dass die Teilnehmer sich einig sind, dass der Plan in seiner aktuellen Form innerhalb des vorgegebenen Zeitrahmens umgesetzt werden kann.

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 seien. Andere Unternehmen führen hingegen vierteljährlich ein PI Planning Meeting durch. Zeitpunkt und Häufigkeit hängen jedoch davon ab, wie lange die einzelnen Program Increments dauern sollen. 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.

Werfen wir nun einen kurzen Blick zurück, bevor wir fortfahren. Denn je nachdem, wie Sie Agile umsetzen, müssen Sie für das PI Planning tatsächlich Vorbereitungen treffen. Ganz genau, wir sprechen hierbei vom Pre-PI Planning (SAFe macht die eher einfallslosen Namen durch gute Systeme und Verfahren wett).

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

Die Vorbereitung hat einen wichtigen Hintergrund: Sie soll sicherstellen, dass der ART im Rahmen des breiteren Solution Train ausgerichtet ist, bevor ein PI Planning durchgeführt wird. Es geht darum, sich mit den anderen ARTs abzustimmen, was dafür sorgt, dass das Projekt und das Unternehmen eine gemeinsame Ausrichtung fokussieren.

Stellen wir uns das einmal am Beispiel von „Thomas, die kleine Lokomotive“ vor: Thomas, Percy und James sind separate ARTs, die sich zu einer besonders effektiven Lokomotive zusammenschließen und getrennte Ladungen für denselben übergeordneten Zweck transportieren.

🚂 Thomas würde die Passagiere befördern

🚂 Percy würde das Feuerwerk abholen

🚂 James würde das Essen für das Picknick liefern

… und alle hätten eine wunderbare Zeit miteinander.

Aber zurück zu Pre-PI Planning Events. Normalerweise finden die Schlüsselpersonen aus dem Solution Train mit den Vertretern der ARTs und den relevanten Suppliers zusammen. Nachfolgend 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
• Systemarchitekten/-ingenieure
• Kunden

Sie 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 Begriffe wie SAFe, Scrum, Roadmaps und Programme richtig zu definieren. Hoffentlich geht Ihnen – falls nicht schon geschehen – ein Lichtlein auf. In 3, 2, 1 ..

Was hat SAFe mit PI Planning zu tun?

Wir sind keine großen Fans von komplizierten Akronymen, doch SAFe sollte man kennen. Die Abkürzung steht für „Scaled Agile Framework™“.

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

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, etablierte Unternehmen (die oft tausende Entwickler beschäftigen) können mit der Innovationsträchtigkeit kleinerer, flexiblerer Start-ups nicht mithalten. Größere Unternehmen verfügen nicht nur über umfassendere Teams: Oft müssen auch deutlich strengere Kontroll- und Compliancevorschriften eingehalten werden, was die Geschwindigkeit ebenfalls dämpft. Es kann drei bis vier Jahre dauern, bis diese größeren, komplexeren Unternehmen 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 ein Hindernis für die rechtzeitige Markteinführung von Projekten 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.

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.

Hier kommt PI Planning ins Spiel …

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 häufigeren Änderungen sowie einer besseren Zusammenarbeit – ein Miteinander statt ein Gegeneinander wird geschaffen. Von diesem Punkt aus können diese Unternehmen ihre Prozesse beschleunigen, effizienter arbeiten, mit neueren sowie flexibleren Wettbewerbern konkurrieren und weiterhin am Markt bestehen.

Randnotiz: SAFe ist zwar ein Framework für größere Unternehmen, doch es gibt keinen Grund, der gegen den Einsatz einer Variante von PI Planning in kleineren Betrieben spricht. Es lohnt sich bereits ab zwei Agile-Teams.

Wenden wir uns nun einer weiteren Definition zu …

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. Hier eine Frage, die häufiger gestellt wird:

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

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

Ihre 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:

• das aktuelle Increment (festgelegte Arbeit)
• das nächste prognostizierte Increment (geplante Arbeit auf Grundlage der prognostizierten Ziele)
• das darauffolgende Increment (weitere geplante Arbeit auf Grundlage der prognostizierten Ziele)

Wenn Sie vierteljährlich ein PI Planning Meeting durchführen, ergibt 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 erstreckt sich in der Regel über mehrere Jahre, wobei für das erste Jahr spezifischere (z. B. vierteljährliche Features und Potenziale) und für das zweite Jahr sowie 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 Programm?

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 über „Team of Teams“ oder Agile-Skalierung spricht, meint derjenige damit, dass der Agile-Ansatz für mehr als nur ein Team verwendet wird.

Nehmen wir an, vier Teams arbeiten an einer NASA-Raumschiffsmission 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 Probezeit ist die NASA der Ansicht, dass dieses Agile-Dings wirklich gut zu funktionieren scheint. Daher werden drei weitere Teams auf Agile umgestellt. Jedes dieser vier Teams organisiert sich selbst und ist damit für seine eigene Arbeit verantwortlich. Da diese Teams nun 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 Owners, das Produktmanagementteam, den Systemarchitekten/-ingenieur und den Release Train Engineer hinzuziehen, sind alle Rollen, die für eine kontinuierliche System- oder Lösungsbereitstellung über den Agile Release Train erforderlich sind, abgedeckt.

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. Schalten wir nun in einen anderen Gang und sprechen wir 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.

Die 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

Die Scrum Master sind Servant Leaders des Product Owner und des Entwicklungsteams, 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 am Confidence Voting 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.

Aber wie bereitet man eigentlich seine Teams und den Raum vor Beginn des Meetings richtig vor?

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 Vorbereitungsmaßnahmen, 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 erreicht werden.

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 Brownies 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 in Ihr Projektmanagement-Tool (z. B. Jira)
• ein Blick auf die Kalender
• die Absprache der Meetingzeiten 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 Planning Events. Hierunter fällt die Zusammenführung der ART-Stakeholder über alle Agile Release Trains innerhalb des Solution Train hinweg, um sicherzustellen, 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 First-of-Five-Vertrauensvotums geprüft, um sicherzustellen, dass sie die Solution Objectives erfüllen. Sie werden so lange überarbeitet, bis im Durchschnitt drei Finger hochgehalten werden.

Doch wie verhält es sich mit PI Planning Events für verteilte Teams und Remote-Teammitglieder? Wie arbeiten sie über Planning Boards zusammen, wie tätigen sie Confidence Votes und wie handhaben sie weitere gleichartige Abläufe? Die erfolgreiche Durchführung eines PI Planning Events, an dem sowohl Menschen vor Ort als auch außerhalb des Raums teilnehmen, ist möglicherweise mit zusätzlichen Herausforderungen verbunden.

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:

Gruppierung vor Ort

Anstatt dass sich alle Beteiligten von ihren eigenen Remote-Locations einklinken, sollten Sie dafür sorgen, dass sie sich bestmöglich vor Ort versammeln und gemeinsam einwählen. 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.

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 die unnötige Speicherung der Infos an zehn oder mehr Orten vermieden werden.

Ü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 Videolivestream 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 dieselbe Erfahrung, 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. Darüber profitieren auch Teammitglieder, die selbst am Meeting teilgenommen haben, von einer solchen Aufzeichnung, z. B. wenn sie ihr Gedächtnis auffrischen wollen.

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.

Aufkommende Fehler und Herausforderungen

PI Planning verläuft nicht immer … na ja, nach Plan und auch das Framework als solches kann eine Herausforderung für einige Unternehmen darstellen. Nachfolgend beschreiben wir diverse häufige Fehler und Challenges, 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 Videostreams 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.

Zeitdruck

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 ART mit acht Teams.

Abweichung vom Ablauf

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. Wie bereits erwähnt: Dieser Ansatz ist wenig intuitiv und geht mit beträchtlichem Kontextverlust einher, insbesondere was die Abhängigkeiten betrifft.

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.

Machen Sie es wie etwa die Unternehmen Boeing und Vodafone und verwenden Sie Jira, um das PI Planning in Kombination mit Easy Agile Programs (verfügbar auf dem Atlassian Marketplace) durchzuführen.

Lesen Sie mehr über Jira und Easy Agile Programs im Blogartikel: Die Rationalisierung Ihrer Workflows dank besserer PI Planning Software.