Rückblick und Ausblick
Im ersten Teil dieser Blog-Serie wurde auf das Coaching der Rollen Product Owner (PO), Proxy Product Owner (PPO) und Business Analyst (BA) sowie auf die Rahmenwerke und Methoden SAFe, Scrum und Agile Requirements Engineering eingegangen. Dort, wo ein Agile Coach fehlt, kann ein Agile Business Analyst von SwissQ wertvoll unterstützen. Er ist ein Experte in Agilität und Business Analyse und bringt nicht nur die dafür notwendigen Aus- und Weiterbildungen mit, sondern auch fundierte Praxiserfahrung aus verschiedenen traditionellen und agilen Vorhaben.
In diesem zweiten Teil erläutere ich, wie die Events Pre-PI Planning* und PI Planning gewinnbringend organisiert und moderiert werden. Dabei agiert der Agile Business Analyst auf Program Level und unterstützt den PM wie auch den RTE bei den Events und eruiert die richtigen Inputs und Outputs. Im Weiteren wird auch auf das PO Sync und das BA Sync eingegangen.
*In der Theorie von SAFe wird das Pre-PI Planning für mehrere Agile Release Trains (ART) empfohlen. In der Praxis kann es von Vorteil sein, das Pre-PI Planning auch bei einem ART durchzuführen. Auf das Post-PI Planning wird an dieser Stelle nicht eingegangen.
Event Facilitation
Pre-PI Planning
SAFe empfiehlt bei mehreren agilen Release Trains - als Vorbereitung für das PI Planning - ein Pre-PI Planning durchzuführen. Dieses dient dem ART dazu, sich auf das bevorstehende PI Planning vorzubereiten. Unter anderem werden dort die Input Ziele und die Meilensteine koordiniert und der Geschäftskontext aller Beteiligten bewusst gemacht.
Dieser Anlass kann im Vorhaben auch dann von grossem Nutzen sein, wenn es lediglich einen ART gibt. Gerade bei frisch gestarteten Vorhaben, die am Reifen sind und wo noch nicht alles klar ist für die Beteiligten, ist das Pre-PI Planning äusserst wertvoll. Eine grosse Unterstützung während dieses Events kann der Agile Business Analyst sein, welcher die Vorbereitungen und die Moderation des Meetings nach Rücksprache mit dem RTE übernehmen kann.
Inputs und Outputs
Damit der Anlass effizient durchgeführt werden kann würde der Agile Business Analyst in einem solchen Szenario- zusammen mit dem Product Management - die Inputs für das Pre-PI Planning vor. Darunter fallen die folgenden Artefakte:
- Vision, z.B. durch das Product Management erstellt (zur Auffrischung und Inspiration, warum wir alle hier sind).
- Roadmap (inhaltlich für einen ART), z.B. durch den Agile Business Analyst erstellt und laufend aktualisiert. Enthält Milestones (u.a. PI, fixe-date und learning Milestones) mit den dazugehörenden Epics und Features, abgebildet auf einer Zeitachse.
- Business Context, z.B. grob formuliert durch den Business Owner.
- Objectives, z.B. durch das Product Management SMART* definierte Jahresziele oder/und PI Ziele für das bevorstehende PI.
- Features, die mit dem bevorstehenden PI Planning geplant werden sollen.
*SMART: Specific, Measurable, Achievable, Realistic, Time-bound
Von grossem Vorteil ist es, alle diese vorgenannten Artefakte in eine zusammenhängende Dokumentation zu packen. Dies ist für den Agile Business Analyst aufwändig, zahlt sich jedoch während und nach dem Anlass für alle Beteiligten wie folgt aus:
- Alle Beteiligten folgen dem gleichen Dokument.
- Kein Wechsel zwischen verschiedenen Collaboration-Tools.
- Alle arbeiten mit den gleichen Informationen.
Die Dokumentation legt der Agile Business Analyst zentral und für alle zugänglich ab, um die Transparenz zu fördern. Diese dient im Anschluss als Informationsgrundlage für das kommende PI Planning. Im Program Backlog und allenfalls auf der Roadmap nimmt der Agile Business Analyst die notwendigen Anpassungen vor.
Zu den wichtigsten Outputs des Pre-PI Planning zählen die zu planenden Features und das Confidence Vote der PI-Objectives um mit dem PI zu starten sowie die PI-Objectives selbst. Diese Outputs verstehen sich gleichzeitig als Inputs für das kommende PI Planning.
PI Planning
Das PI Planning ist der Herzschlag des ART. Der Agile Business Analyst unterstützt den Release Train Engineer bei den Vorbereitungen und der Moderation. Im Weiteren steht der Agile Business Analyst dem Product Management zur Seite und weist dieses bei Bedarf auf notwendige Handlungen hin. Zusammen mit dem Release Train Engineer kann der Agile Business Analyst u.a. auch dafür besorgt sein, dass alle Agile Teams die erarbeiteten PI Planning Inputs (vgl. Absatz zu Pre-PI Planning in diesem Blog) verstehen und diese im Planning korrekt verwenden (der Fokus liegt auf dem ART).
Inputs und Outputs
Ähnlich wie für das Pre-PI Planning, stellen der Release Train Engineer und der Agile Business Analyst eine Präsentation zusammen. Diese ist als roter Faden für das PI Planning zu verstehen und beinhaltet u.a. die folgenden Punkte:
- Agenda
- Vision
- Roadmap
- Business Context
- Features (top 10), die im Pre-PI Planning bestimmt wurden
Der Agile Business Analyst kann auch während des Events die POs und die Scrum Master (SM) bei Fragen unterstützen, insofern das Notwendige Agile Know How vorhanden ist. Jede Aktivität der Agile Teams soll dem Kunden einen Mehrwert bringen (der Fokus liegt auch hier auf dem ART).
Zu den Outputs zählen die PI Objectives der Agile Teams (SMART formuliert, inkl. Business Value von Business Owner und committed durch Agile Teams) und das Program Board (visualisiert mit Features, Abhängigkeiten und Meilensteine).
Sync Meetings
Ein teamübergreifender BA Sync (gleiches gilt für den PO Sync) hilft im Vorhaben, dass sich die BAs methodisch und thematisch synchronisieren können, z.B. einmal wöchentlich 30 bis 60 Minuten (vgl. auch Kadenz und Synchronisierung bei SAFe). Der Agile Business Analyst kann diesen Sync mit seiner Teilnahme als Moderator unterstützen. Er ist Ansprechpartner bei Fragestellungen zu u.a. folgenden Themen:
- Rahmenwerke wie Scrum und SAFe
- Agile RE-Methoden
- Lean-Agile Mindset
- Program Backlog
- Planning Aktivitäten
- Product Engineering
- Features
- Aktuelles vom Program Management
Tipp
Je grösser die Anzahl der Teilnehmenden, desto wichtiger ist es, dass es explizite Sync-Verhaltensregeln gibt. Diese sollten allen BAs zugänglich und bekannt sein. Für den Moderator empfiehlt sich ein Regiebuch zu schreiben. Dieses gibt ihm selbst Halt und dem Sync Struktur.
Fazit
Der Agile Business Analyst unterstützt mit seinem Wissen zu Product Engineering das Product Management. Dies kann er tun indem er u.a., in dem er an Anlässe wie z.B. das Pre-PI Planning, das PI Planning sowie kadenzbasierte Sync Meetings teilnimmt. Er kann je nach Bedarf auch moderieren und co-moderieren, dies auch in Vereinbarung mit dem Release Train Engineer. Der Agile Business Analyst kann in diesem Kontext als Coach betrachtet werden. Das Product Engineering Poster kann hierbei helfen den Kunden als Zentrum des Vorhabens zu verstehen.
Es handelt sich bei der Blog-Serie nicht um eine Liste von abschliessenden Aufgaben und Aktivitäten, sondern um einen Auszug wegweisender Tätigkeiten, die einem Agile Business Analyst im Kontext von SAFe mit dem Product Management begegnen können. Die Blog-Serie geht von einem Vorhaben aus, das von einem ART mit fünf Scrum Teams realisiert wird.
Ausblick auf den 3. Teil der Blog-Serie: Backlog Management
Im dritten Teil der Blog-Serie erfahren Sie, wie der Agile Business Analyst die Backlogs und Kanban Boards für Epics und Features mitgestaltet und verwaltet. Im Weiteren wird aufgezeigt, wie mit Themen umgegangen wird, die mehrere Produkte und Agile Teams im Vorhaben betreffen. Wie wird sichergestellt, dass alle das gleiche verstehen um das gemeinsame Ziel zu erreichen? Lesen Sie weiter, der Mehrwert ist garantiert.
