Product Engineering und Product Management im Kontext von SAFe – Teil 3 von 3


Stefan Gisin, Consultant Requirements Engineering

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. Der agile Business Analyst ist ein Experte in Agilität & Business Analyse und bringt nicht nur die dafür notwendigen Aus- und Weiterbildungen mit, sondern auch fundierte Praxiserfahrung aus verschiedenen traditionellen und agilen Vorhaben.

Im zweiten Teil dieser Blog-Serie wurde erläutert, wie die Events Pre-PI Planning* und PI Planning organisiert, moderiert sowie die Inputs und die Outputs eruiert werden können. Im Weiteren wurde auf die PO- und BA-Sync eingegangen.

Der dritte und letzte Teil geht auf die verschiedenen Backlogs und Kanban Boards ein. Dabei liegt der Fokus des dritten Teils auf dem Management von Epics, Features und transversalen* Themen und wie der Einsatz eines agilen Business Analysten auf Level Epic aussehen kann.

*In diesem Kontext haben transversale Themen Berührungspunkte mit mehreren Agile Teams.

Backlog Management

Backlog Management

Copyright und Quelle: Stefani Gisin, SwissQ

Epic

SAFe unterscheidet zwischen Business Epics, die einen direkten Business Value liefern und Enabler Epics, welche Anforderungen an die Architektur darstellen. Die Epics können dabei als Themen Container angesehen werden. Sie dienen zur Umsetzung von grösseren Vorhaben auf einer hohen Flugebene. Sie dauern oft mehrere Program Increments (PI).

Pro Epic wird ein Set an Features definiert, welches der Definition des Minimum Viable Product – MVP gleichkommt. Dies mit der Absicht, der Unsicherheit entgegenzuwirken (vgl. auch SwissQ-Blog Minimal Viable Product leicht gemacht). Der agile Business Analyst kann im Epic-Kontext das Lean Portfolio Management und den Epic Owner bei der Erhebung, dem Schreiben der Hypothesen und der Definition des MVPs (der Agile Business Analyst legt dazu den Fokus auf den Feedback-Loop von Build – Measure – Learn) unterstützen.

Erhebung und Dokumentation

Eine gute Variante für die Erhebung der Epics sind Workshops.
Hier ein Beispiel für einen Ablauf, wie ein solcher Workshop erfolgen kann, wenn man eine grüne Wiese vor sich hat:

  • Die Vision verstehen: Beteiligte lesen die Vision in Ruhe durch (die Vision liegt für alle greifbar, physisch vor).
  • Die Vision fragmentieren: Beteiligte erkennen Fragmente in der Vision, die in einzelne, Lösungen aufgeteilt & entwickelt werden können.
  • Die Fragmente ‚einmalig‘ machen: Jedes Fragment erhält einen kurzen, verständlichen und einmaligen Namen (Epic Name).
  • Die Fragmente beschreiben: Für jedes Fragment wird eine klare Beschreibung festgelegt, die einer vordefinierten Satzschablone folgt.
  • Den Fragmenten nicht funktionale Anforderungen zuweisen: Interessenspersonen wie z.B. Software- und Systemarchitekten definieren grobe nicht funktionale Anforderungen (pro Epic oder Epic übergreifend).
  • Kriterien der Akzeptanz festlegen: Jedem Epic werden Akzeptanzkriterien zugewiesen, die ein Epic erfüllen muss und dienen zum Schluss für die Akzeptanz der gestalteten Lösung und der damit verbundenen Arbeiten (Akzeptanzkriterien können später auch dazu verwendet werden, um Features abzuleiten).
  • MVP definieren: Für jeden Epic definieren die Beteiligten die minimalen Anforderungen für eine frühe und einfache, validierbare Version des Produkts.
  • Epic Walkthrough: Alle Epics für alle Interessensgruppen im Vorhaben zugänglich machen und anhand von Walkthroughs Reviews durchführen.
  • Refinement: Alle Epics finalisieren, priorisieren und auf dem Kanban Board sichtbar machen.

Der agile Business Analyst kann diese Workshops beim Fehlen eines Moderators organisieren und moderieren. Als Grundlage dient die Vision. Abgeleitet davon motiviert der agile Business Analyst die Beteiligten, Epics zu identifizieren. Dabei gilt es einzelne, in sich geschlossene Themen aus der Vision abzugrenzen und daraus Epics zu schneiden. Besonders gut eignet sich dazu eine Tafel, auf der mit Post-its mögliche Container sichtbar gemacht werden. In mehreren Iterationen bestimmen die Beteiligten die Themen Container (von der Breite in die Tiefe), die der agile Business Analyst in die folgende Struktur (ist als Variante zu verstehen) bringt:

  • Epic Name
  • Angaben zum Epic Owner
  • Kurze, verständliche Beschreibung des Epics (Satzschablone kann verwendet werden)
  • Auf den Epic bezogene nicht funktionale Anforderungen
  • Akzeptanzkriterien
  • Nach Bedarf weitere Angaben

Portfolio Kanban

Jedem Epic wird ein Epic Owner zugeordnet, der als inhaltlicher Eigentümer, während der Laufdauer eines Epics, agiert. Der Epic Owner ist Ansprechpartner und der agile Business Analyst kann als Unterstützung hinzugezogen werden. Damit die Epics im Vorhaben gelesen und gelebt werden, müssen sie sichtbar sein. Dazu eignet sich ein Kanban Board. Das Board sollte allen zugänglich sein und aufzeigen, welchen Status ein Epic gerade aufweist (von der Ideenfindung bis zur fertigen Umsetzung). In einem regelmässig stattfindenden Portfolio Sync prüft das Lean Portfolio Management die Epics auf ihre Aktualität und nimmt allenfalls notwendige Anpassungen vor. Der agile Business Analyst kann diesen Sync moderieren oder auch die Anpassungen vornehmen. Der Epic Owner ist in jedem Fall für die korrekte Abbildung auf dem Kanban Board verantwortlich. Da der agile Business Analyst mit vielen unterschiedlichen Interessensgruppen (u.a. BAs und POs) in Kontakt ist, ruft er die Epics und das Kanban Board immer wieder ins Bewusstsein dieser Personen und weist auf die Wichtigkeit hin. Gerade in jungen Vorhaben, bei denen der Reifegrad noch tief ist und einige Abläufe und Gewohnheiten nicht gefestigt sind, nimmt der agile Business Analyst und das Product Management hierbei einen wichtige Aufgabe des fehlenden, agilen Coaches wahr.

Ein wahrer Produkt Held

Der agile Business Analyst hat bei seinen Aktivitäten, in Zusammenhang mit den Epics, den Fokus auf dem Übergang zwischen Product Discovery und Product Design (Product Engineering Poster). Damit wird bewusst, dass der agile Business Analyst im Product Engineering eine zentrale Rolle einnimmt. Dabei sind die Kunden wie auch das Produkt als Mittelpunkt des Vorhabens, von Product Discovery, zu Product Design bis hin zu Product Delivery zentrale Elemente.

From Discovery to Design

From Discovery to Design; Copyright und Quelle: SwissQ

Feature

Auf Feature Level übernimmt der agile Business Analyst üblicherweise zusammen mit dem Product Management die Dokumentation der Features, die sich aus den Epics ableiten. Ein Feature ist gemäss SAFe genau so gross/klein geschnitten, dass es von einem Agile Release Train (ART) während eines Programm Increments (PI) umgesetzt werden kann. Features können auch aus dem Kontext eines ART hervorgehen. Folglich ist es in der Praxis nicht unüblich und sogar erwünscht, dass Agile Teams selbst auch Features definieren und schreiben.

Der agile Business Analyst kann, zusammen mit den BAs, Struktur-Vorlagen für Features erstellen. Dieser unterbreitet zudem Vorschläge für die inhaltliche Struktur von Features und entwickelt diese mit den Ideen der BAs weiter. Es ist zielführend, wenn alle möglichen Feature-Autoren mitbestimmen können, aus welchen Attributen ein Feature bestehen soll. Dabei ist zu beachten, dass die Vorlage agil, leicht zu verstehen und einfach anzuwenden ist. Des Weiteren achtet er darauf, dass u.a. POs, Architekten und UX Designer ebenfalls ihre Inputs zur Struktur liefern können. Denn diese Interessensgruppen sind teilweise Adressate oder Co-Autoren von Features.

Auch sinnvoll kann es sein, wenn die mit einem Feature mitgelieferten Artefakte vordefiniert sind. Beispiele dafür sind:

  • Prozessbeschreibungen (z.B. als Business Process Model and Notation – BPMN).
  • Klassendiagramme (z.B. als Unified Modeling Language – UML).
  • Modelle der Anwendungsdomäne (z.B. in Anlehnung an Domain Driven Design – DDD).

Programm Kanban

Das Product Management visualisiert den Fluss der Features im Programm Kanban. Der agile Business Analyst achtet darauf, dass die dokumentierten Features die korrekte Struktur und die notwendigen Artefakte aufweisen, ist diese nicht vorhanden, darf sich auch gerne das Team zu Wort melden.  Er aBA spricht sich mit den Agile Teams und dem Product Management ab, damit alle Interessensgruppen den Inhalt der Features, bereits vor dem PI Planning, verstehen und in den Gesamtkontext der Produkteentwicklung einordnen können, insofern kein RTE vorhanden ist. Auf dem Kanban Board ordnet der Product Manager mit unterstützung des agilen Business Analysten die Features regelmässig dem entsprechenden Status zu (z.B. Funnel, Analyzing, Validating, Deployment). Dabei sind diese stets in regem Austausch mit den Interessensgruppen, fragen bei Unklarheiten nach, geben Informationen weiter und fördern dadurch die Transparenz und die Ausrichtung zur gemeinsamen Zielerreichung.

Die Features werden im Loop des Product Designs formuliert und bieten die inhaltliche Grundlage für die Stories, die im Fokus von Product Delivery liegen.

From Design to Delivery

From Design to Delivery; Copyright und Quelle: SwissQ

Transversale Themen Container

Im Product Engineering gibt es immer Themen und Bedürfnisse, die für mehrere Agile Teams von Interesse sind. Dies liegt u.a. daran, dass agile Teams keine spezialisierten Silos sind, sondern crossfunktional, sprich Disziplinen übergreifend aufgestellt sein sollten.  In einem ART arbeiten agile Teams autonom zusammen und ziehen sich selbständig die priorisierten Features zur Umsetzung aus dem Programm Backlog. Die Berührungspunkte zu Fach- und Technologiethemen sind daher oft dieselben oder ähnlich.

Damit Doppelspurigkeiten vermieden werden und eine gemeinsame Ausrichtung zum Produktziel ermöglicht wird, können Fokusgruppen gebildet werden. Eine Fokusgruppe besteht aus einer Ansprechsperson und weiteren (ca. 2 bis 5) Gruppenmitgliedern. Die Herausforderung im ART besteht darin, nicht zu viele und nicht zu wenige Fokusgruppen zu bilden. Es sollten lediglich Fokusgruppen für Themenbereiche konstituiert werden, für die es nach SAFe kein passendes Gefäss gibt. Immer im Auge die Komplexität und Kommunikationsstrukturen nicht unnötig in die Höhe zu treiben. Auch Simplicyt ist ein agiles Prinzip! Gerade für BAs können Fokusgruppen nützlich sein. Sie schreiben Stories und stellen dabei Abhängigkeiten fest, die sie mit ihren Kolleginnen und Kollegen besprechen müssen. Die Fokusgruppe trifft sich regelmässig, jedoch nur gerade so oft wie notwendig und richtet sich auf ein gemeinsames Ziel aus. Der Outcome kann der Ansprechpartner für eine Fokusgruppe, z.B. anlässlich des PO Sync oder des BA Sync, kommunizieren.

Fazit

Epics sind Themen Container und werden durch das Lean Portfolio Management, mit Unterstützung durch den agile Business Analyst, dokumentiert und im Portfolio Kanban abgebildet. Features sind Services, die in der Obhut des Product Managements liegen und durch den agile Business Analyst im Program Backlog dokumentiert und im Program Kanban abgebildet werden. Features können auch durch agile Teams geschrieben werden. Der agile Business Analyst koordiniert den Austausch zwischen agile Teams und Product Management. Themen und Bedürfnisse, die mehrere agile Teams berühren, können proaktiv im PI in Fokusgruppen diskutiert werden. Damit werden früh Doppelspurigkeiten vermieden und das gemeinsame Verständnis gefördert.

0 thoughts on “Product Engineering und Product Management im Kontext von SAFe – Teil 3 von 3”


    Schreibe einen Kommentar