Zeigt den Blog Namen

PI Planning: Im Kontext von Zügen und Bahnhöfen

Wer sich mit Business Agility beschäftigt, befasst sich früher oder später mit dem Scaled Agile Framework (SAFe®) und damit mit drei zentralen Elementen. Was ist ein Agile Release Train, was ein Programm-Inkrement und welche Erfahrungen aus der Praxis unterstützen mich als Release Train Engineer oder Scrum Master bei der Organisation und Durchführung des PI Planning?

 

Die Wertschöpfungsmaschine: Der ART

Der Agile Release Train bildet das Herzstück für Planung, Design, Implementation und Lieferung von Produkten und Dienstleistungen in einer definierten Wertschöpfungskette (Value Stream). Als virtuelle Organisation setzt sich ein ART aus 50 bis 125 funktionsübergreifenden Leuten zusammen, die sicher eine gemeinsame Mission ausrichten. Arbeiten mehr als 125 Leute an derselben Lösung, werden mehrere ARTs in einem Solution Train organisiert. Im Grundsatz entspricht diese Form der Organisation der Idee von „Team of Teams“ oder „Scrum of Scrums“.

Agile Release Trains werden nach dem Produktlebenszyklusausgerichtet und können dementsprechend lange unterwegs sein. Dies ist einer der grossen Unterschiede zum traditionellen Projekt-Geschäft. Egal ob Komponenten für die Automobil-Branche oder eine Mobile Applikation für den App-Store: funktionierende Teams und Agile Release Trains bleiben zusammen und arbeiten in vielen Fällen über Monate und Jahre an einer gemeinsamen Vision. Dabei richtet sich der Agile Release Train kontinuierlich neuen Marktgegebenheiten und Anforderungen aus. Was für Version 2.0 hip war, wird für Version 3.0 bereits wieder überarbeitet. Auf seiner Reise entlang des Produkt-Lebenszyklus schafft der ART einen kontinuierlichen Fluss an Wert für seine Kunden.

 

Ein gemeinsamer Takt: Das Programm-Inkrement

PI PlanningStellt man sich den ART wie einen richtigen Zug vor, dann ist das Programm-Inkrement die Strecke zwischen zwei Bahnhöfen. Der Zug folgt einem fix definierten Takt und erreicht in gleichbleibenden Abständen den jeweils nächsten Bahnhof. Ein Programm-Inkrement ist standardmässig zwischen 8 und 12 Wochen lang. Der Zug kommt damit immer pünktlich am nächsten Bahnhof an, was für entsprechende Metriken (zum Beispiel Velocity) hinsichtlich Vorausschaubarkeit des ART und seiner Teams essentiell ist. Anders als in traditionellen Projekt Management Methoden gelebt, reihen sich mit einem ART Etappen von gleichbleibender Länge aneinander. Diese werden in sich geplant, ausgeführt und so auslieferbare Inkremente erarbeitet.

 

Rollt der Zug in einen Bahnhof ein, werden Waren ab- und zugeladen, Menschen steigen aus oder kommen hinzu. Die Waren stehen dabei für umgesetzte beziehungsweise neue Anforderungen. Verpasst eine Anforderung den Zustieg an einem Bahnhof, hat sie beim nächsten eine neue Gelegenheit. Die kontinuierliche Priorisierung der Waren durch das Produktmanagement bestimmt die Reihenfolge, das Fassungsvermögen (ART Velocity) die Menge an Waren, welche auf den Zug aufgeladen werden.

 

Programm-Inkremente bilden überschaubare Etappen hin zur Vision. Arbeiten zig Teams über einen langen Zeitraum an einer gemeinsamen Vision, hilft der beste Projektplan nicht weiter. Zu viele Faktoren ändern sich auf der Reise. Anforderungen, Technologien, Markt und Know-How der Leute, um nur einige zu nennen. Deshalb bilden Programm-Inkremente überschaubare Etappen hin zur Vision – und damit einen Rahmen für den ART, in regelmässigen Abständen zurück und nach vorne zu schauen. Genau dies geschieht an den Bahnhöfen. In SAFe® sprechen wir von zwei Events. Dem Inspect&Adapt und dem PI Planning.

 

  • Inspect&Adapt: Zum einen inspizieren wir den Fortschritt unseres Produktes. Was haben wir erreicht? Welche neuen Funktionalitäten haben wir geliefert/sind lieferbar? Was halten unsere Stakeholder von den Ergebnissen? Zum anderen reflektiert sich der ART selbst: Welche Prozesse funktionieren, welche nicht? Haben wir alle nötigen Fähigkeiten und Kompetenzen, um gemeinsam erfolgreich zu sein? Wo sollten wir mit neuen Ansätzen experimentieren? Beides führt zu Inputs für das PI Planning, in Form eines überarbeiteten Product Backlog mit zum Beispiel neuen oder angepassten Anforderungen und Massnahmen zur Verbesserung der Prozesse.
  • PI Planning: Die Autoren von SAFe® sagen: “There is no magic in SAFe… except maybe for PI Planning.”
    Was die Magie eines PI Plannings ausmacht und welche Praktiken sich in der Praxis bewährt haben, ist Teil des nächsten Abschnitts.

 

 

Ein grosses Zusammenkommen: Das PI Planning

In regelmässigen Abständen, dem gemeinsamen Takt, treffen sich alle Beteiligten eines ART um sich zu synchronisieren und das nächste Programm-Inkrement zu planen. Die Teams, Product Owner, Scrum Master, Das Produkt Management, Business Owner und auch Vertreter aus Marketing, HR und Sales, … alle Stakeholder finden sich ein um sich gemeinsam auf eine Mission zu begeben. Schaffen eines gemeinsamen Verständnisses, Seilziehen um Prioritäten und treffen wichtiger Entscheide, alles passiert an einem Ort und ohne Verzögerungen. Das PI Planning schafft damit in zwei Tagen einen hohen Grad an Alignment und Transparenz, unverzichtbare Voraussetzungen für den gemeinsamen Erfolg.

Bei der Planung und Durchführung des Events gibt es aus bisherigen Erfahrungen der Experten erfolgskritische Faktoren, aufgeteilt in die Phasen vor, während und nach dem PI Planning:

 

Vor dem Planning:

  1. Backlog Readiness: Das Program Backlog muss in hoher Qualität vorliegen. Das Program Management und die Product Owner sind gut beraten, bereits vor dem Planning die Teams mit denPI Planning Backlog Items zu konfrontieren. Nur so bleibt genügend Zeit, fehlende Aspekte einzelner Anforderungen bis zum Planning zu erarbeiten. Eine klar definierte und von allen Seiten akzeptierte „Definition of Ready“ hilft dabei, Qualitätsmängel in den Anforderungen festzustellen.
  2. Das Facility Management behandelt scheinbar simple Organisationsfragen, die aber für den Erfolg sehr wichtig sind, denn jede Panne kann teuer werden. Zimmer, Essen, Anfahrt, Räume, Sitzordnung, Infrastruktur, diese Punkte müssen sorgfältig geplant und vorbereitet sein. Falls in verteilten Teams geplant wird, muss ein besonderes Augenmerk auf die Infrastruktur gelegt werden. Videokonferenzen müssen störungsfrei funktionieren, Zeitzonen im Voraus berücksichtigt und beim visuellen Arbeiten ein Verfahren gewählt werden, welches die Zusammenarbeit fördert. Für die Durchführung von PI Plannings mit verteilten Teams siehe auch 10 essentials for a distributed PI Planning.
  3. PI Planning Simulation: Es empfiehlt sich vor dem ersten PI Planning eine Simulation durchzuführen. Alle teilnehmenden Rollen sollen sich mit dem Game Plan vertraut machen und ein PI Planning auf spielerische Art und Weise erleben, bevor es Ernst gilt. Wichtig: Benutzt dabei Test-Daten. Es soll sich nicht um eine Vorab-Planung handeln, sondern den Prozess an sich in den Mittelpunkt stellen. Eine PI Planning Simulation gibt dem Release Train Engineer und den Scrum Master wertvolle Hinweise auf mögliche Risiken und Falltüren.

 

Während des Plannings:

  1. Purpose: Warum kommen wir zusammen um zwei Tage zu planen? Alle Teilnehmenden verdienen die Antwort auf diese Frage. Deshalb sind die Präsentationen des Business Kontexts und der Produkt Vision so eminent wichtig. Diese zwei Punkte in der Agenda eines jeden PI Planning bieten den Vertretern des Business (im besten Fall ein Executive) und dem Produkt Management die einmalige Chance die Leute zu inspirieren und damit für das kommende Programm-Inkrement zu motivieren.
  2. Scrum of Scrums: in regelmässigen Abständen helfen fokussiert zu bleiben, an den richtigen Dingen zu arbeiten und die nötige Transparenz zu schaffen. Die Scrum Master zusammen mit dem Release Train Engineer bilden eine verschworene Einheit. Entsprechend müssen sie gründlich trainiert und auf mögliche Szenarien vorbereitet sein. Checklisten unterstützen dabei zum richtigen Zeitpunkt die richtigen Fragen zu stellen und alle Partien abzuholen.
  3. PI Objectives: spielen eine zentrale Rolle. Mit Ihnen schliesst sich der Feedback Loop zwischen den Teams, den Erwartungen aus dem Business und den priorisierten Program Backlog Items. Gute PI Objectives entstehen aus guten Plänen. Regelmässige Reviews der Pläne helfen den Teams zu verstehen, in was sie sich hineingeben. Erst mit der Zuweisung von Business Value schliesst sich der Feedback Loop. Trotzdem nicht vergessen: Der Wert eines PI Plannings findet sich in den unzähligen Diskussionen und Übereinstimmungen während des Plannings.

 

Nach dem Planning:

  1. Kontinuierliche Verbesserung: Die Retrospektive muss nicht bis zum Schluss warten. Die Teilnehmenden werden ohnehin müde sein nach zwei Tagen Planung. Deshalb: Hängt in der Kaffee-Ecke Flipcharts auf und sammelt bereits am ersten Tag Rückmeldungen. Damit kann der zweite Tag des Plannings verbessert werden.
    Das Augenmerk soll während des PI Plannings auf den Quick-Wins liegen: Verbesserungen, welche alle unverzüglich spüren. Nach dem Planning fliessen die Erkenntnisse aus der Retrospektive in ein Verbesserungs-Backlog, welches nach Wert in Bezug auf den gesamten ART priorisiert wird.
  2. Das Program Board, ist nebst den PI Objectives das wichtigste Resultat aus dem PI Planning. Im visualisierten Plan mit den Abhängigkeiten zwischen den Teams widerspiegelt sich sozusagen der Fahrplan für das Programm-Inkrement. Voll mit wichtigsten Informationen ist das Programm Board ein nützliches Instrument nach dem PI Planning. In Scrum of Scrums und PO Sync Meetings können Abhängigkeiten kontinuierlich besprochen und so Risiken minimiert und verhindert werden. Allfällige Einflussfaktoren und mögliche Änderungen lassen sich auf dem Program Board gut in Szenarien diskutieren und Konsequenzen abschätzen.

 



Weitere kritische Erfolgsfaktoren bezüglich PI Planning finden sich auch in den Episoden von „5 Things I wish I’d known before my first PI Planning



 

Jeder Zug braucht einen Ingenieur

Der Release Train Engineer, eine Rolle, geprägt und definiert vom Scaled Agile Framework, ist auf bestem Weg sich in allen Branchen und Organisationen zu etablieren. Das System Agile Release Train braucht einen starken RTE, gewillt funktionierende Praktiken durchzusetzen aber auch die nötige Offenheit, mit neuen Ansätzen zu experimentieren, um den Zug in der Erfolgsspur zu halten.

Ich hoffe mit diesem Beitrag jeden RTE, aber auch die Scrum Master in deren ungemein wichtigen Rollen zu stärken.

 


Die perfekte Gelegenheit sich mit anderen Release Train Engineers und Scrum Master auszutauschen, bietet sich am RTE Summit in Amsterdam am 11. und 12. November, See you there!


 

Wir verwenden Cookies, um Ihnen die beste Online-Erfahrung zu bieten. Mit Ihrer Zustimmung akzeptieren Sie die Verwendung von Cookies in Übereinstimmung mit unseren Cookie-Richtlinien.

Privacy Settings saved!
Datenschutz-Einstellungen

Wenn Sie eine Website besuchen, kann sie Informationen über Ihren Browser speichern oder abrufen, meist in Form von Cookies. Steuern Sie hier Ihre persönlichen Cookie-Dienste.

These cookies are necessary for the website to function and cannot be switched off in our systems.

Um diese Website nutzen zu können, verwenden wir die folgenden technisch erforderlichen Cookies
  • wordpress_test_cookie
  • wordpress_logged_in_
  • wordpress_sec

Wir nutzen WooCommerce als Einkaufssystem. Für die Warenkorb- und Bestellabwicklung werden 2 Cookies gespeichert. Diese Cookies sind unbedingt erforderlich und können nicht deaktiviert werden.
  • woocommerce_cart_hash
  • woocommerce_items_in_cart

Alle Cookies ablehnen
Alle Cookies akzeptieren