Vom Projektleiter zum Product Owner in der „Agile Product Delivery“

Vom Command and Control zu „Agile Product Delivery“ 

In Scrum Teams mit mehreren fachlichen Disziplinen ist das klare Verständnis der Product Owner (PO) Rolle eine kritische Erfolgsvariable. Nur wenn es ein ehemaliger Projektleiter in seiner Scrum Rolle des PO versteht die „Agile Product Delivery“ umzusetzen, wird er ein Produkt erfolgreich auf den Markt bringen.  [1]. In derartigen Scrum Teams hat ein PO hat fünf Schwerpunkte in seiner Rolle zu erfüllen:

  • Die Product Vision entwickeln und diese operationalisieren (Epic, Topic, Story).
  • Mit jeder Epic, mit jedem Topic und mit jeder Story Business Value  generieren.
  • Entlang von Business Value und Produktentwicklung priorisieren.
  • Agiles Planning entlang von Milestones, die die Timeline abbilden, durchführen.
  • Laufende Riskkontrolle und matching seiner angenommenen Durchlaufzeit mit der empirischen Realität der emprischen Prozesskontrolle.

Um diese zentralen Aufgaben zu erfüllen, ist das sogenannte „Collaborative User Story Writing“ ein wesentliches Erfolgskriterium. Nur ein Mindset des PO, dass er ein Teil, nicht mehr und nicht weniger, eines Scrum Teams ist, kann diese Aufgabe erfüllt werden. Ein PO ist kein besserer Experte in einer Fachdisziplin, der PO gibt dem Development Team keine Fachlösungen vor und er trifft keinerlei Entscheidungen über die einzusetzende technische Lösung. Projektleiter, die sich zu einem PO entwickeln, haben damit in ihrer ersten Produktentwicklung zumal erhebliche Schwierigkeiten. Der Scrum Master muss dem PO hierbei dabei unterstützen, vom „Command and Control Mindset“ zu einem kollaborativen Mindset, mit Akzeptanz von Planungsunsicherheiten, zu wechseln. Zumal muss er gar der Cerberus des Development Teams sein, wenn ein PO mit Command and Control über das Ziel hinausschießt.

User Story Writing Workshop

Im Idealfall startet jede Produktentwicklung mit einem User Story Workshop auf Basis der Product Vision des PO. Im kollaborativen Setting geht es für das Scrum Team darum ein gemeinsames Verständnis der Epics und notwendigen User Stories herzustellen. Dem Scrum Team wird damit ermöglicht, die Art und Weise der User Stories kennenzulernen, und Expertise für die Sprint Plannings und Estimations zu entwickeln. Eine erste Komplexitätszuordnung funktioniert mit relativen Größen. Wir verwenden  gerne Maus, Tiger und Elefant. Im Backlogrefinement funktioniert das ähnlich, nur dass wir hier feingranularer werden.

User Story Writing Workshop, Kobald Agile Expert & IT-Projects, 2017

Der Ablauf sollte folgender sein:

  1. Die richtigen Teilnehmer dabei haben: Entwickler, Tester, UX-Designer, SW-Architekt, Business Analyst, Hardwareentwickler, Elektronikentwickler, Optikentwickler, Produktion, etc.
  2. Fokusierung auf die Epics. Der PO ordnet diese in einer ersten Priorisierung entland eines Zeitstrahls.
  3. Die Epics gemeinsam auf kleinere Stories herunterbrechen.
  4. User Story festhalten, die auch mehrere Sprints benötigen können.
  5. Auf einem Witheboard mit Sticky Notes den Zusammenhang der Stories sichtbar machen.
  6. Zuerst Konzentration auf das Minimum Viable Product (MVP) und Minimum Marktable Feature (MMF).

Die Agile Product Delivery

Für die Agile Product Delivery sind vier Meetings zu unterscheiden:

  1. User Story Mapping.
  2. Backlog Refinment.
  3. Sprint Planning.
  4. Release Planning.

Die Meetings eins bis drei sollen unbedingt das gesamte Scrum Team involvieren (collaborative user story design). Das vierte Meeting ist für den PO, um realistische Releases zu plannen. Hierzu sollten je nach Fragestellung die notwendigen Stakeholder vom PO eingeladen werden.

 

 

 

[1] Ellen Gottesdiener, 2017, Slicing User Stories, Delivering Value