Die dreiteilige Blog-Serie ist ein Muss für Begeisterte von Scaled Agile Framework (SAFe). Die einzelnen Beiträge vermitteln einen Einblick in die Tätigkeiten eines Agile Business Analysten, der mit seinem Wissen über Product Engineering das Product Management unterstützt. Der Fokus liegt auf dem Wissenstransfer. In dieser Blog-Serie werden Beispiele aus der Praxis grob und vereinfacht wiedergegeben. Optimal werden die geschilderten Situationen durch einen erfahrenen Agile Coach unterstützt. Es handelt sich nicht um eine Liste von abschliessenden Aufgaben und Aktivitäten, sondern um einen Auszug wegweisender Tätigkeiten, die einem Agile Business Analysten im Kontext von SAFe mit dem Product Management begegnen können. Die Blog-Serie geht von einem Vorhaben aus, das von einem Agile Release Train (ART) mit fünf Scrum Teams realisiert wird.
Blog-Serie mit drei Teilen
Teil 1 - Coaching
In diesem ersten Teil wird auf das Coaching der Rollen Product Owner (PO), Proxy Product Owner (PPO) und Business Analyst (BA) sowie auf die Rahmenwerke und die Methoden SAFe, Scrum und Agile RE eingegangen.
Teil 2 - Event Facilitation
Der zweite Teil erläutert, wie die Events Pre-PI Planning und PI Planning organisiert und moderiert sowie die Inputs und die Outputs eruiert werden können. Im Weiteren wird auf das PO Sync und das BA Sync eingegangen.
In der Theorie wird das Pre-PI Planning für mehrere 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.
Teil 3 - Backlog Management
Der dritte und letzte Teil geht auf die verschiedenen Backlogs und Kanban Boards ein. Dabei liegt der Fokus auf dem Management von Epics, Features und transversalen Themen.
In diesem Kontext haben transversale Themen Berührungspunkte mit mehreren Agile Teams.
Coaching
Agile Transformation - von klassischen Prozessen zu agilen Rahmenwerke
Immer mehr Organisationen führen ihre Vorhaben mit einem skalierbaren Rahmenwerk (z.B. SAFe) durch. Dabei erleben Mitarbeitende die Transformation von Wasserfall zu agilen Vorhaben oft als grosse Herausforderung. Dies kann u.a. daran liegen, dass die Mitarbeitenden während des Transformationsprozesses nicht ausreichend begleitet werden oder dass die Transformation nur über die Einführung neuer Technologien erfolgt.
Menschen benötigen unterschiedlich viel Zeit, um Änderungen zu verstehen und von der Theorie in die Praxis zu transferieren. Eine frühe und enge Begleitung der betroffenen Mitarbeitenden durch einen Agile Coach kann dabei helfen. Viele von uns werden täglich mit Änderungen konfrontiert und häufig wünschen wir uns etwas mehr Zeit und gezielte Unterstützung, vor allem aber Verständnis für die für uns neue Situation. Das Wort EMPATHIE ist an dieser Stelle grossgeschrieben.
Menschen und ihre Rolle im Vorhaben unterstützen
Dort, wo solche Vorhaben optimal initialisiert wurden, werden die Menschen von Anfang an durch einen Agile Coach unterstützt. Oft fehlt jedoch ein solcher Experte. Der Agile Business Analyst, der das Product Management unterstützt, kann u.a. auch dabei helfen, dass der Kulturwandel, der durch die Transformation entsteht, vom Management nicht unterschätzt wird. Das Management ist zwingend notwendig für die Schaffung der Rahmenbedingungen, damit die Transformation stattfinden kann. Sofern der Agile Business Analyst auch Leadership Fähigkeiten besitzt und ein begeisterter Agilist ist, kann er Menschen und Vorhaben auch im Bereich von Agile Coaching unterstützen.
SAFe nennt einige Rollen. Unter anderem ist der PO eine davon, wenn es darum geht, Anforderungen zu verwalten. Damit jedoch nicht genug. Ein PO (vgl. auch den SwissQ-Blog Product Owner - Die eierlegende Wollmilchsau) wird mit viel mehr Aufgaben konfrontiert. Um diese zu bewältigen, erhält der PO in der Praxis häufig Unterstützung durch einen Proxy PO oder einem oder mehreren BAs. Die Besetzung dieser drei Rollen erfolgt dann oft durch Organisationsinterne Mitarbeitende. Diese werden mit viel Neuem konfrontiert. Der Agile Business Analyst kann hierbei mit seinem Gesamtüberblick über das Vorhaben das Agile Coaching von PO, PPO und BA übernehmen.
Rahmenwerke und Methoden im Vorhaben verständlich machen
Product Backlog Management
Es empfiehlt sich, mit Terminblocker zu arbeiten. Zum Beispiel planen der Agile Business Analyst und der PO jede Woche einen Austausch während 60 Minuten ein. Die Timebox kann langfristig verkürzt werden, da die Notwendigkeit der Unterstützung für den PO eher abnimmt. Gestartet werden kann mit einem Theorieteil zu z.B. Scrum, SAFe und Continuous Improvement.
Eine weitere Möglichkeit ist das gemeinsame Analysieren des Produkt-Backlogs. Der Agile Business Analyst stellt dem PO Fragen zur Art der Priorisierung sowie zu möglichen Abhängigkeiten zwischen Stories oder zur Dringlichkeit und Wichtigkeit der Anforderungen. Aus der Rückmeldung des PO kann der Agile Business Analyst erkennen, welche Gedanken sich der PO bereits gemacht bzw. noch nicht gemacht hat. Auch spürt er, ob der PO ausreichend mit den Backlog-Items vertraut ist und den Inhalt versteht. Eine ebenfalls gewinnbringende Methode ist das Shadowing. Der Agile Business Analyst ist als Zuhörer an einem Scrum Sprint Planning Meeting anwesend. Es ist wichtig, dass der Agile Business Analyst vorab die Teilnahme mit dem PO abspricht und das ganze Team über seine Anwesenheit informiert. Um die Transparenz noch weiter zu erhöhen, kann der Agile Business Analyst seinen Fokus (z.B. Anwendung von Methoden, Wahrnehmung von Rollen, Einhalten von Timeboxes) vorab ebenfalls allen Teammitgliedern kommunizieren. Der Agile Business Analyst notiert sich während des Scrum-Sprint-Planning-Meetings seine Erkenntnisse zu den Fokusthemen. Diese bespricht er danach mit dem PO oder auch mit den anderen Teammitglieder und deckt damit blinde Flecke auf. Damit ein nachhaltiger Mehrwert generiert wird, wiederholt der Agile Business Analyst seine Anwesenheit im Scrum-Sprint-Planning-Meeting und äussert seine Erkenntnisse als Feedback an den PO.
Es soll jedoch an dieser Stelle auch gesagt sein, dass die obgenannten Tätigkeiten normalerweise vom Scrum Master übernommen werden.
Agile Requirements Engineering
Der Agile Business Analyst sollte mit den POs und den anderen BAs zusammenarbeiten und sie bei der Findung und Implementierung der passenden Dokumentationsmethoden und Modellierungsmethoden unterstützen. Z.B. beim Eruieren, ob Behaviour Driven Development (BDD) und Domain Driven Design (DDD) passende Methoden sind. Im Produkt Backlog der Agile Teams erfolgt die Dokumentation durch User Stories (benutzerzentriert geschrieben) und Enabler Stories (der Fokus liegt auf der technischen Formulierung). Der Agile Business Analyst kann hierbei mit den POs und den BAs Vorlagen für Stories ausarbeiten (SAFe bietet dazu umfassende Informationen an und SwissQ hat die passenden Kurse). Weiterführende Eindrücke zu Agile Requirements Engineering finden sich im SwissQ-Blog Agiles Requirements Engineering - Die unterschätzte Disziplin.
Fazit
Menschen, die von einer Agile Transformation betroffen sind, benötigen Begleitung und vor allem Zeit, um das Lean-Agile-Mindset zu verinnerlichen. Die Begleitung wird üblicherweise durch einen erfahrenen Agile Coach wahrgenommen. Fehlt dieser, kann ein Agile Business Analyst, der dem Product Management zur Seite steht, aushelfen. Die Kerntätigkeit eines Agile Business Analysten liegt darin, das Program Board mit Features zu füllen. Wenn der Agile Business Analyst Coaching-Fähigkeiten hat, kann er z.B. POs, PPOs und BAs coachen. Im Weiteren kann er mit seinem Wissen zu Dokumentationsmethoden und Modellierungsmethoden den POs und den BAs zur Seite stehen und sie entsprechend unterstützen.
Ausblick auf den 2. Teil der Blog-Serie: Event Facilitation
Im zweiten Teil der Blog-Serie erfahren Sie, warum es sinnvoll sein kann, wenn der Agile Business Analyst das Product Management und den Release Train Engineer beim organisieren und moderieren von Plannings und Sync Meetings unterstützt. Bleiben Sie neugierig und lesen Sie weiter.
