Eine der zentralen Rollen im Scrum ist der Product Owner. Die meisten Unternehmen, die versuchen Scrum zu etablieren, haben oft wenig Probleme Team und Scrum Master zu besetzen. Beim Product Owner sieht das oft ganz anders aus.
"Der Product Owner ist für die Eigenschaften und den wirtschaftlichen Erfolg des Produkts verantwortlich. Er gestaltet das Produkt mit dem Ziel, seinen Nutzen zu maximieren. Der Nutzen könnte sich beispielsweise am Umsatz des Unternehmens orientieren. Er erstellt, priorisiert und erläutert die zu entwickelnden Produkteigenschaften, und er urteilt darüber, welche Eigenschaften am Ende eines Sprints fertiggestellt wurden. Er ist eine Person, kein Komitee. Ihm allein obliegt die Entscheidung über das Produkt, seine Eigenschaften und die Reihenfolge der Implementierung. So balanciert er Eigenschaften, Auslieferungszeitpunkte und Kosten."
- Seite „Scrum“. In: Wikipedia, Die freie Enzyklopädie. Bearbeitungsstand: 6. Juli 2017, 12:34 UTC. URL: https://de.wikipedia.org/wiki/Scrum
Ein Product Owner in dieser Form ist seltener als eine Oase in der Wüste. Stattdessen werden die abenteuerlichsten Konstrukte gebaut, um die Aufgaben das Product Owners irgendwie wahrzunehmen.
- Der Product Owner im Mittelstand
- Der Product Owner in großen Unternehmen
- Interessenausgleich
- Overpowered Product Owner
- Underpowered Product Owner
- Product Owner als Schlüssel zu Agilität
Der Product Owner im Mittelstand
In mittelständischen Unternehmen findet man häufig folgende Situation: Ein Mitarbeiter wird als Product Owner benannt. Er kann aber keine Entscheidung fällen, ohne Rücksprache mit der Geschäftsführung - und die Geschäftsführung überstimmt auch gerne mal seine Entscheidungen. Eigentlich ist der Geschäftsführer der wahre Product Owner und der benannte Product Owner übernimmt eher Sekretariatsaufgaben: JIRA Tickets schreiben oder am lästigen Daily Scrum teilnehmen. Weitere Stakeholder sind meist nicht beteiligt und Entscheidungen fallen nach Gutsherrenart. Anforderungen anderer Stakeholder oder des Teams werden meist soweit runterpriorisiert, dass eine Realisierung praktisch ausgeschlossen ist. Der wahre Product Owner ist nicht nur "empowered", sondern "overpowered".
In großen Unternehmen findet man genau die gegenteilige Ausprägung. Auch hier gibt es etwas, wie einen Product Owner, aber meist ohne Entscheidungsbefugnis und ohne eine klare Vision. Eine einzelne Person, die über das Produkt entscheidet, kann es in so einem Setup nicht geben. Stattdessen sind etliche Stakeholder aus ihrer Rollendefinition oder Linienfunktion sogar noch mit Veto-Recht ausgestattet: Governance, Enterprise Architektur, Datenschutz, Betriebsrat, Operations, u.v.a. Der Product Owner ist hier massiv "underpowered" und kann keine klaren Entscheidungen treffen. Die Stakeholder stellen, gestützt auf ihr Veto-Recht, Maximalforderungen und eine Priorisierung des Backlogs oder gar eine sinnvolle Release-Planung ist praktisch unmöglich. Der Product Owner ist "underpowered".
Eine der wichtigsten Aufgaben des Product Owners ist es, das "minimum viable product" - kurz MVP - zu definieren. Dazu ist es notwendig, die Interessen der Stakeholder auszubalancieren und den notwendigen minimalen Funktionsumfang für ein erstes Release zu definieren. Da in diesem Prozess viele Anforderungen der Stakeholder zurückgestellt werden müssen, um sie in späteren Projektphase erst zu realisieren, müssen praktisch alle Stakeholder von ihren Vorstellungen Abstand nehmen. Daher ist es notwendig, dass der Product Owner ausreichend "empowered" ist, um diese schwierigen und oft unbequemen Entscheidungen ggf. alleine zu fällen. Das Team tritt in diesem Prozess als eigener Stakeholder auf und definiert technische Anforderungen, Refactorings und Verbesserungen, die genauso vom Product Owner, idealerweise in einen vertrauensvollen Dialog, bewertet und priorisiert werden müssen.
In dem Fall, dass der Geschäftsführer die Rolle des Product Owner direkt oder indirekt einnimmt, findet der Interessenausgleich meist nur rudimentär statt und der Product Owner definiert das "minimum viable product" willkürlich von oben herab. Daher kommen wichtige Anforderungen, meist nicht-funktionaler Natur, z.B. Sicherheit, zu kurz oder es werden technische Schulden aufgebaut. Immerhin wird das Produkt früh ausgeliefert und kann und muss sich beim Kunden bewähren.
Schlimmer für das Endprodukt ist die Situation, wenn die Rolle des Product Owners zur Unkenntlichkeit verwässert wird. Stakeholder mit Veto-Recht können ihre Maximalforderungen einfach durchsetzen. Eine gemeinsame Vision ist durch Gremien und Linienorganisation zerredet worden und das Team nutzt die Schwäche des Product Owners aus, indem die vermeintliche Qualität durch endlose Refactorings und goldene Wasserhähne "gesteigert" wird. Der Kundennutzen ist nur noch ein Randaspekt und der wirtschaftliche Erfolg des Produkts wird zur Nebensache. Ein frühes Release eines Produkts, das nur die aller wichtigsten funktionalen und nicht-funktionalen Anforderungen abdeckt, ist praktisch unmöglich. Stattdessen wird Sprint für Sprint an einem überladenen Produkt gearbeitet und trotz agiler Rituale ist das Projekt vollkommen "unagil".
Agilität ist ohne einen Product Owner, der diesen Namen auch wirklich verdient, praktisch unmöglich. Er hat eine Vision von seinem Produkt. Und das ist mehr, als eine grobe Idee, wie es mal werden soll. Er hat eine Mission. Er will die Welt verbessern mit seinem Produkt, und zwar so schnell wie möglich. Die Rolle des Product Owner orientiert sich an der Lean-Startup-Methodik und versucht die Gesetzmäßigkeiten eines Startup-Unternehmens für Projekte nutzbar zu machen.
"Lean Startup ist eine Methode für die Entwicklung von Unternehmen und Produkten. Die Methodik zielt darauf ab, die Produktentwicklungszyklen zu verkürzen, indem sie eine Kombination von Business-Hypothese-getriebenen Experimenten, iterativen Produktreleases und validiertem Lernen anwenden."
- Übersetzung von Seite „Lean Startup“. In Wikipedia, Die Freie Enzyklopädie. Bearbeitungsstand: 12 Juli 2017, 11:49 UTC. URL: https://en.wikipedia.org/wiki/Lean_startup
Der Product Owner ist der "Gründer" des Projektunternehmens und muss unternehmerisch denken. Er hat ein vitales Interesse, sein Produkt an den Markt zu bringen, bevor das Geld der Investoren ausgeht. Der Product Owner muss einerseits als Moderator die unterschiedlichen Stakeholder an einen Tisch bringen und versuchen einen Interessenausgleich zu erreichen. Auf der anderen Seite ist er aber auch ausreichend "empowered", um Anforderungen, von wem auch immer, abzulehnen oder zumindest zurückzustellen. Wenn es nicht gelingt, die Rolle des Product Owners mit einer Person, mit einer Vision, integrativen Fähigkeiten und Durchsetzungsfähigkeit zu besetzen, wird ein unagiles Produkt mit agilen Ritualen entwickelt. So schwer es auch fällt: Der Product Owner ist eine Person, kein Komitee.
Noch Fragen?
Wie können Sie agile Methoden in Ihrer Organisation umsetzen, damit sie einen echten Mehrwert liefern? Erfahren Sie, wie wir Sie unterstützen können:
Guido Zockoll - arbeitet als Senior Software-Architect bei der iteratec GmbH in Hamburg. Von der Hardware-Entwicklung zur Software-Architektur, vom Projekt- und Programm-Management zur Personalführung. In über 20 Jahren in der Softwareentwicklung haben ihn immer die Zusammenhänge interessiert. Dabei ist er ein Mensch der Praxis.