Der Product Owner nimmt in Scrum eine sehr zentrale Rolle ein, die oft mit sehr hohen Erwartungen verbunden ist. Er soll das Produkt gestalten, seine Produktvision in das Team tragen und für Klarheit und Transparenz durch ein gut gepflegtes Product Backlog und frühzeitig lauffähige Software sorgen. Schnelle Wertschöpfung zu erzielen und dabei unterschiedliche Anforderungen zahlreicher Stakeholder zu erfüllen, ist eine schwierige Aufgabe.
Also wählt man am besten den fähigsten Manager für diese Schlüsselrolle aus?
Leider haben diese Personen oft bereits zahlreiche andere wichtige Aufgaben zu erfüllen, so dass zu wenig Zeit für die wirksame Ausübung der Product Owner Rolle übrig bleibt. Zudem führen häufige Unterbrechungen und Kontextwechsel zu einem erheblichen Produktivitätsverlust wie Gerald Weinberg in seinem Buch mit dem Titel „Quality Software Management: Systems Thinking“ aufzeigt.
Die Abbildung zeigt, dass bei drei gleichzeitigen Projekten bereits 40% Verlust durch Kontextwechsel entstehen und für ein einzelnes Projekt nur 20% übrig bleiben. Möglichkeiten der Ablenkung und Unterbrechung bieten sich heutzutage mehr als genug: das E-Mail-Postfach läuft über, der Instant Messenger macht sich ständig bemerkbar, das Handy klingelt und man hat das Gefühl, mit der eigenen Arbeit gar nicht voran zu kommen.
Um diesen Problemen zu begegnen, muss das Management die Product Owner Rolle mit Bedacht besetzen und gemeinsam mit dem Product Owner die notwendigen Randbedingungen schaffen. Das bedeutet, sich über die Verantwortlichkeiten der Rolle intensiv Gedanken zu machen und festzulegen, welche Aufgaben, mit welchen Stakeholdern, unter Verwendung welcher Methoden, konkreter Techniken und Werkzeuge zu erfüllen sind. Besteht hierzu Konsens fehlt noch ein weiterer wichtiger Schritt: die Verantwortlichkeiten und Aufgaben des Product Owners müssen an alle Projektbeteiligten klar kommuniziert werden, und das Management muss die notwendige Legitimation erteilen!
Hierzu möchte ich im Folgenden ein Vorgehen in vier Schritten vorstellen:
Schritt 1: Aufgabenbereiche und Tätigkeiten ermitteln
Der Product Owner maximiert den Wert des Produktes. Er kennt seine Kunden, verwaltet und priorisiert die Anforderungen und steuert dadurch die Entwicklung. Welche Aufgaben leiten sich daraus ab?
Sammeln sie beispielsweise mit Hilfe der Brainstorming-Technik konkrete Tätigkeiten und clustern sie diese in grobe Aufgabenbereiche, z.B.
- Kommunikation (mit Kunden und Nutzern)
- Requirements Engineering (Ermitteln, Dokumentieren, Abstimmen, Prüfen)
- Zusammenarbeit mit dem Team (Anforderungen verfeinern, Sprints planen, Feedback geben, …)
- Messen, schätzen, planen und berichten
Am besten verfeinern sie dann einzelne Tätigkeiten, in dem sie diskutieren und festhalten, in welchem Kontext die jeweilige Tätigkeit durchgeführt wird, z.B.
- in welchem Termin oder Gremium?
- mit welcher Frequenz? (täglich, wöchentlich, quartalsweise, …)
- wie viel Zeit wird benötigt?
- mit welchen anderen Personen?
Bei der Diskussion kommt häufig die Frage auf, ob der Product Owner die betreffende Tätigkeit selbst ausführt, oder ob er lediglich das Ergebnis verantwortet. Um dies klarzustellen können sie die identifizierten Tätigkeiten mit Hilfe der RACI-Technik kennzeichnen.
Schritt 2: Vollständigkeit und Korrektheit prüfen
Um die Vollständigkeit und Korrektheit der in Schritt 1 ermittelten Aufgaben zu prüfen, nehmen sie eine andere Perspektive ein. Führen sie hierzu eine Stakeholder-Analyse durch und betrachten für jeden Stakeholder, welche Erwartungen dieser Stakeholder an das Projekt und den Product Owner hat. Gleichen sie ab, ob die ermittelten Aufgaben zur Erfüllung der Stakeholder-Erwartungen passen und welche Tätigkeiten ggf. noch fehlen.
Darüber hinaus kann man die Artefakte und Werkzeuge betrachten, die im Rahmen des Projektes entstehen bzw. zum Einsatz kommen. Dabei wird jeweils verifiziert, welche Aufgaben und Verantwortlichkeiten dem Product Owner bei der Erstellung und Pflege eines Artefaktes zukommen. Dabei sollte man unter anderem an folgende Dinge denken:
- Produktinkrement
- Product Backlog, Anforderungen in Form von Epics und User Stories
- Usablity Engineering Ergebnisse, z.B. UI-Prototypen, Ergebnisse von Nutzertests
- Releases, Releasepläne, Release-Notes usw.
- Kapazitätsplan
- Risiko-Management-Plan
Schritt 3: Dinge, die ein Product Owner nicht tun sollte
Klare Aufgaben und Verantwortlichkeiten? Prima! Es ist aber ebenso wichtig, dass der Product Owner und auch die anderen Projektbeteiligten genau wissen, welche Dinge ein Product Owner nicht tun sollte. Hierzu ist es sehr hilfreich, sich mit den agilen Prinzipien zu beschäftigen und sich Gedanken über die Zusammenarbeit zwischen Product Owner, Development Team und Scrum Master zu machen.
Eine sehr kurzweilige und effiziente Kreativitätstechnik, die sich dazu anbietet, ist das „Brainstorming paradox“. Aus der Sicht des Product Owners stellt man dabei eine provokante Frage, z. B. „Wie bringe ich das Development-Team gegen mich auf?“.
Zu den typischen Fehlern zählen unter anderem folgende Punkte. Der Product Owner …
- ist nicht verfügbar,
- macht klassisches „Command & Control Mikromanagement“,
- versteht sich als Chef des Teams,
- mischt sich in die technische Lösungsdiskussion ein,
- übernimmt oder beeinflusst Aufwandsschätzungen.
Schritt 4: Für Legitimation und Transparenz sorgen
Der Product Owner benötigt eine verbindliche Legitimation, d.h. die Unterstützung und volle Ermächtigung des Managements, damit er die Rolle erfolgreich ausfüllen kann. Besonders wichtig ist die Entscheidungsbefugnis bezüglich der genauen Formulierung von Anforderungen und deren Priorisierung.
Fassen sie die Ergebnisse der Schritte 1 bis 3 zusammen und diskutieren Sie mit dem Management, welche Randbedingungen erforderlich sind, um die Aufgaben zu erfüllen. Wenn es Randbedingungen gibt, welche hinderlich sind oder der Aufgabenerfüllung widersprechen, formulieren sie möglichst einfache Maßnahmen, um die Randbedingungen zu verändern. Hierbei hilft ihnen die SMART-Regel, d.h. die Lösungen sollten (S)pezifisch, (M)essbar, (A)kzeptiert/(A)ktionsorientiert, (R)ealistisch und (T)erminiert ein. Sorgen sie dafür, dass allen Beteiligten klar ist, dass der Product Owner seiner Verantwortung nur dann gerecht werden kann, wenn er dazu die notwendig Bevollmächtigung und Zeit (Kapazität) bekommt.
Damit auch andere Projektbeteiligte ein klares Bild der Product Owner Rolle haben, lohnt es sich die Ergebnisse zu visualisieren. Erstellen sie dazu beispielsweise zwei Poster und hängen diese gut sichtbar auf. Ein Poster illustriert die Aufgaben und Verantwortlichkeiten, das andere visualisiert die Dinge, die ein Product Owner nicht tun sollte.
Fazit
Diese vier Schritte helfen dabei, die Rolle des Product Owners zu definieren, für den notwendigen Spielraum zu sorgen und vom Management die erforderliche Ermächtigung einzuholen. Da sich die Randbedingungen im Laufe der Zeit natürlich ändern können, sollte man auch die Ausgestaltung der Product Owner Rolle regelmäßig hinterfragen.
Gerne unterstützen wir sie bei der Scrum-Einführung und klaren Ausgestaltung der Product Owner Rolle.
