Sind mehrere Product Owner nötig, um Scrum effektiv zu skalieren? Nein.
Dass in skalierter Produktentwicklung mehrere Product Owner von Nöten sind, ist ein weit verbreiteter Irrglaube!
Dieser Beitrag räumt mit diesem Irrglauben auf. Wird die Product Owner Rolle durch mehrere Personen skaliert, führt es zu
- Wertminimierung,
- steigendem Risiko und
- unnötiger Verlängerung der Time to Market.
Es ist somit eine ineffektive Art, Product Ownership zu skalieren.
Fehlinterpretation der Product Owner Rolle ist der Ursprung des Irrglaubens
Es gibt verschiedene Gründe, wie es zu dieser falschen Auffassung kommt, und alle gehen auf eine gemeinsame Ursache zurück: Die Fehlinterpretation der Product Owner Rolle.
Product Owner muss alle Arbeiten selber übernehmen
"Der:die Product Owner:in ist auch für ein effektives Product‐Backlog‐Management ergebnisverantwortlich [...]" -- Scrum Guide 2021
Dieser Satz aus dem Scrum Guide kann so interpretiert werden, dass der Product Owner alle Dinge, welche für das Management des Product Backlogs nötig sind, selber übernehmen muss. Lesen wir jedoch weiter, erfahren wir:
"Der:die Product Owner:in kann die oben genannten Arbeiten selbst durchführen oder die Umsetzungsverantwortung an andere delegieren. Unabhängig davon bleibt der:die Product Owner:in ergebnisverantwortlich." -- Scrum Guide 2021
Das Schlüsselwort ist "delegieren"! Wenn es keine Beachtung findet, führt es zur Fehlinterpretation, dass der Product Owner alle Arbeiten selbst übernehmen muss.
Product Owner kann nur zwei Teams unterstützen
Viele Organisationen setzen auf das Scaled Agile Framework (SAFe), um mehrere Teams, die an demselben Produkt arbeiten, aufeinander abzustimmen. Um es in den Worten von Willem-Jan Ageling zu sagen:
“Die Rollenbeschreibung des Product Owners in SAFe und in Scrum stimmen lediglich in dessen Namen überein.”
Der Product Owner in SAFe ist für den Team Backlog verantwortlich und dieser enthält nur die Anforderungen an ein Team. Nach SAFe kann ein Product Owner diese Aufgabe nur für bis zu zwei Teams übernehmen. Die hohe Verbreitung -- nach dem 14.th Annual State of Agility Report verwenden 35% der Organisationen die Skalierungsmethode SAFe -- trägt zur Verbreitung der Fehlinterpretation bei, dass der Product Owner nur bis zu zwei Teams unterstützen darf.
Ein großes Produkt braucht ein Product Owner Gremium
In traditionell geprägten Organisationen wird die Verantwortung für ein großes Produkt häufig von einer Gruppe von Personen, häufig Produkt Managern, übernommen. Werden bei der Einführung von Scrum diese existierenden Strukturen nicht aufgelöst, sondern nur umbenannt, führt dies dazu, dass aus der Gruppe von Produktverantwortlichen ein Gremium von Product Ownern wird.
Alle drei Fehlinterpretationen der Product Owner Rolle tragen zur Verbreitung des Irrglaubens bei, dass es in skaliertem Scrum mehrere Product Owner gibt.
Ein Product Owner, um Scrum zu skalieren
Der Scrum Guide, welcher die Regeln für Scrum enthält, hält unmissverständlich fest:
Der:die Product Owner:in ist eine Person, kein Gremium. -- Scrum Guide
Diese Regel sollte auch nicht aufgeweicht werden, wenn mehrere Scrum Teams gemeinsam an einem Produkt arbeiten.
Skaliertes Scrum fußt auf der Rule of One, welche besagt:
- ein Product
- ein Product Backlog
- ein Product Owner
Sie hilft, Scrum effektiv zu skalieren, da sie die Verantwortung für das Produkt in einer Person, dem Product Owner, bündelt und dadurch transparent macht.
Wertminimierung durch langsame Entscheidungsfindung
Sind hingegen mehrere Product Owner für ein Produkt verantwortlich, müssen Entscheidungen in Gremien getroffen werden, damit sich alle Beteiligten einbringen können. Diese Art der Entscheidungsfindung dauert zwangsläufig länger. Dies führt zu einem Wettbewerbsnachteil gegenüber der Konkurrenz, wie eine Umfrage von McKinsey unter 1400 Führungskräfte aus verschiedenen Branchen, Regionen und Eigentümerstrukturen ergab. Derzufolge glaubten 60 Prozent der Befragten, dass Entscheidungsprozesse wesentlich länger dauern als die der Wettbewerber. Aufgrund langsamer Entscheidungen ist die Reaktion auf sich ergebende Veränderungen drastisch erschwert und Investitionschancen werden schlechter genutzt. Dieser Nachteil gegenüber der Konkurrenz minimiert den Wert des Produkts.
Gesteigertes Risiko durch intransparente Produktverantwortung
Wie der Name impliziert, besitzt der Product Owner das Produkt. Das bedeutet, er repräsentiert wie kein anderer im Unternehmen das Produkt und dessen Zukunft. Seine Entscheidungen und seine Vision vom Produkt geben die Richtung für die Produktentwicklung vor. Die Produktvision, welche erst durch den Product Owner lebendig wird, eint die Scrum Teams hinter einem gemeinsamen Ziel.
Der Product Owner macht nicht nur die Vision transparent, sondern auch die Verantwortung für das Produkt. Er ist der erste Ansprechpartner für alle Belange rund um die Zukunft des Produkts. Nur als einzelne Person ist er zu jeder Zeit aussagefähig. Verteilt man diese Verantwortung auf mehrere Personen, wird die Transparenz geschmälert. Transparenz, Überprüfung und Anpassung bilden die Grundlage für die Feedbackschleife in Scrum, mit welcher Risiken reduziert werden. Ist diese Schleife gestört, da die Verantwortlichkeit für das Produkt nicht transparent ist, hilft Scrum nicht mehr dabei das Risiko zu reduzieren.
Verlängerung der Time to Market aufgrund fehlender ganzheitlicher Produktsicht
Übernimmt eine Gruppe die Verantwortung für ein Produkt, müssen die Zuständigkeiten aufgeteilt werden, um effizient arbeiten zu können. Als Resultat geht die ganzheitliche Sicht auf das Produkt verloren. Diese ganzheitliche Sicht ist essentiell für den Erfolg des Produkts, da Kunden keine Teile des Produkts kaufen, sondern immer nur das Produkt als Ganzes!
Wird diese Tatsache aus den Augen verloren, führt es dazu, dass sich Teams nur auf ihren Verantwortungsbereich fokussieren. Sie stellen nur noch ihren Teil der Arbeit fertig und sehen die Integration ihrer Arbeit in das Gesamtprodukt nicht mehr in ihrem Verantwortungsbereich. Wenn diese Verantwortung fehlt, sind Integrationsprobleme unausweichlich. Integrationsprobleme erhöhen die Time To Market und schmälern die Effektivität von Scrum, die Feedbackschleife mit dem Kunden zu schließen.
Product Ownership ist eine Verantwortung
Zusammengefasst ist es höchst ineffektiv, mit mehreren Personen Product-Ownership zu skalieren, da es zu
- Wertminimierung,
- steigendem Risiko und
- unnötiger Verlängerung der Time to Market
führt.
Wenn du mehr darüber erfahren willst, wie Scrum professionell skaliert wird, dann
👉 registriere dich für meinen Newsletter. 👈
Als Steward für Scaled Professional Scrum werde ich dich dort über die neusten Entwicklungen von skalierten Scrum informieren.