Der Product Owner ist eine der drei Rollen, die im Scrum Guide beschrieben sind. Er ist für den wirtschaftlichen Erfolg des zu entwickelnden Produktes verantwortlich. Während sein Blick gemeinsam mit den Entwicklern auf das Produkt gerichtet ist, kümmert sich der Scrum Master überwiegend um den Prozess. Gemeinsam bilden alle drei Rollen das Scrum Team.
Der Product Owner
Der Product Owner ist eine der drei Rollen in Scrum. Neben den beiden Rollen Scrum Master und Entwicklungsteam, kümmert sich der Product Owner federführend um die Anforderungen im Projekt. Er ist für das Product Backlog verantwortlich, eines der drei zentralen Artefakte in Scrum. Nur er darf die Reihenfolge in diesem Backlog bestimmen und ist durch seine Priorisierung in der Lage die Produkteigenschaften des Produktes zu bestimmen. Er hat dafür zu sorgen, dass das Backlog transparent für alle beteiligten Parteien verfügbar ist.
Der Product Owner muss die Wirtschaftlichkeit des Produktes im Blick haben. Er darf Produktentscheidungen treffen und muss diese verantworten.
Verantwortlichkeiten und Aufgabe
Der Product Owner hat diverse Verantwortlichkeiten und Aufgaben, denen er in seiner Rolle gerecht werden muss. Das Product Backlog ist sein Artefakt und nur er ist der Eigentümer dieses Product Backlogs. Er hat die Verantwortung über das Product Backlog und muss für dessen Transparenz sorgen. Die Reihenfolge in diesem Backlog ist ebenso in seiner Hoheit und er kann damit die Effektivität (das "was") des Produktes maßgeblich mit bestimmen. Er ist derjenige, der mit dem Kunden die Wünsche erarbeitet und festhält. Damit hat er auch den ROI (Return of Invest) des Produktes in der Hand.
Der Product Owner hat die Aufgabe zusammen mit dem Kunden eine Vision zu erstellen. Für diese Vision gibt es verschiedene Vorgehen und Formate - ich persönlich mag immer noch die drei bis vier Sätze auf dem Flipchart am liebsten. Er nimmt die Product Backlog Items ab. Am Ende eines Sprints ist er es, der die Product Backlog Einträge abnimmt.
Zeit und Abnahme durch den Product Owner
Der Product Owner kann jederzeit Product Backlog Items vom Entwicklungsteam abnehmen. Das muss nicht am Ende des Sprints erfolgen. Genau genommen ist es natürlich besser, wenn der Product Owner so früh wie möglich fertige Arbeit abnehmen kann.
In einem reifen Team beschränkt sich die Abnahme des Product Owners häufig auf das Feedback. Wenn die Definition of Done und die Akzeptanzkriterien erfüllt sind, sollte die Erwartung getroffen werden.
Ein Product Owner denkt visionär und unternehmerisch. Er besitzt die Produktverantwortung und sollte 50-100% seiner Zeit für ein Produkt und Team aufwenden können. Er sitzt optimal im Teambereich oder ist verfügbar, wenn das Team Rückfragen zu Anforderungen hat. Während er für das Team der Ansprechpartner ist, benötigt es auf der anderen Seite - zu den Stakeholdern - einen Ansprechpartner, den ebenso die Product Owner Rolle einnimmt.
Der Product Owner und die Zeit
Im Scrum Guide finden Sie keine Angabe, wieviel zeit ein Product Owner für ein Team aufbringen muss. Die Werte resultieren aus meiner Erfahrung und Praxiseinsätzen.
Einer der Scrum Werte ist Mut - diesen muss Product Owner selbstverständlich aufbringen (können), denn ab und zu müssen Product Backlog Items entfernt, mit dem Kunden die Reihenfolge diskutiert oder ganz unkonventionelle Wege eingeschlagen werden.
Fassen wir die wichtigsten Aufgaben und Verantwortlichkeiten des Product Owners noch einmal zusammen.
Der Product Owner in Theorie und Praxis
Bei einem Treffen der Agile Augsburg Gruppe haben wir über den Wandel der Product Owner Rolle gesprochen. Ich selbst bin mit der Rolle und dem Ausfüllen dieser Rolle schon vor guten 10 Jahren das erste Mal in Berührung gekommen - damals typisch in der Softwareentwicklung. Die Gruppendiskussionen haben bei mir wieder einige Punkte in der Reflexion angestoßen, die ich hier kurz einmal vorstelle und zur Diskussion stelle.
Aus meiner Sicht gibt es zwei Faktoren, die sich stark auf die gelebte Rolle des Product Owners auswirken. Schauen wir uns beide einmal in der Übersicht an:
Unternehmensgröße
In meiner beruflichen Laufbahn habe ich mehr mit großen, als mit kleinen Unternehmen zu tun gehabt. Auffällig war es für mich immer, dass in großen Organisationen die Rolle des Product Owner weiter weg vom Lehrbuch ist, als in kleinen Unternehmen. Ebenso scheint es mir, es gibt ein Art Selbstverständlichkeit, diese Tatsache in größeren Unternehmen hinzunehmen. Es wird weniger hinterfragt und weniger ausprobiert. Ich tippe auf die Rahmenbedingungen in den Organisationen und auf die Trägheit des Systems als Ganzes, dass sich dieses mir so dargestellt hat. Die Mitarbeiter in großen Organisationen kennen lange Wege in der Hierarchie und bestimmte Dinge werden einfach ausgesessen. Man will sich nicht gleich mit dem Chef anlegen und eine blutige Nase holen. In kleinen Unternehmen herrscht in der Product Owner Rolle der Unternehmergeist. Hier finden Sie häufiger eine Product Owner Rollenimplementierung, die auch empowered ist, Dinge zu entscheiden und zu tun.
Produktlebenszyklus
Eine weitere Beobachtung, die ich immer wieder machen kann: der Produktlebenszyklus ist entscheidend! Finden wir in Unternehmen Product Owner und ein Produkt, dass eine Neuentwicklung darstellt, wird die Rolle besser gelebt und ausgefüllt, als wenn wir Product Owner vorfinden, die ein Produkt betreuen, das schon etwas in die Jahre gekommen ist. Hier spielt sicherlich auch mit hinein, dass die Product Owner dann oft auch nur einen Teil, eine Funktion oder Applikation eines größeren Produktes betreuen. Je "reifer" das Produkt ist und je weniger innovativ es sein muss, desto eher finde ich die Situation, dass der Product Owner (gerne auf frühere Projektleiter) einfach nur das Backlog verwaltet.
Beobachtungen
Die Größe von Unternehmen korreliert in meinen Augen sehr stark damit, ob die Rolle Entwicklunger im Sinne von Scrum cross-funktional aufgestellt wird. Wenn wir einen Product Owner haben, der nicht befähigt ist, hat er selten ein cross-funktional Team bei sich. Der typische Fall ist der, dass hier darauf geachtet wird, in bestimmten Bereichen oder Abteilungen zu denken, nicht aber im Sinne eines Produktes, das in einem Backlog beschrieben wird und von einem Team umgesetzt wird. Typische Ausprägungen sind:
Diskussionen Agile Augsburg
Kein Befähigung / kein Empowerment
Was tue ich denn nun, wenn mein Product Owner nicht befähigt ist? Eine sehr häufige Frage, die immer wieder in Trainings und Workshops bei mir gestellt wird. Die Teilnehmer wissen nämlich schon zu Beginn, dass die Product Owner Rolle nicht so gelebt werden kann, wie sie angedacht ist. Meine erste Antwort ist dann immer:
Scrum Guide
Scrums roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum
Wenn Sie einen schlagkräftigen Product Owner wollen, dann müssen Sie auch auf seine Eigenschaften, Verantwortungen und Aufgaben fokussieren. So funktioniert Scrum und dann, kann Scrum die wahren Vorteile ausspielen. Natürlich geht es auch ohne und es lassen sich viele andere Wege finden. Es ist trotzdem kein Scrum. Was die einen jetzt abtun mit "man muss ja Scrum auch der Realität anpassen" oder "Scrum funktioniert ja nur in der Theorie" ist oft das Ergebnis von Resignation.
Ich kenne es nur zu gut in großen Unternehmen, dass man irgendwann einfach keine Lust mehr hat, die Organisation "überzeugen" zu wollen. Gerade die Scrum Master haben damit alle Hände voll zu tun und diese organisatorischen Ãnderungen dauern eben sehr, sehr lange.
Natürlich ist der Scrum Master die Person, die bei so einem gravierendem Hindernis eingreifen muss. Er ist der Hüter des Prozesses und sorgt dafür, dass alle Scrum machen können. Was so einfach klingt ist leicht gesagt, aber schwer umgesetzt. Und nicht alle Unternehmen sind bereit für Scrum. Und erst recht haben nicht alle Unternehmen ihre Warum-Scrum-Frage beantwortet und an alle kommuniziert.
Wie ersetze ich meinen Product Owner?
Der Product Owner wird schnell zu einer zentralen und tragenden Rolle. Er kennt den Kunden und die Anforderungen an das Produkt sehr genau. Was passiert nun, wenn der Product Owner einmal ausfüllt? Jeder macht Urlaub, der ist planbar. Doch mit Krankheit oder schlimmeren kann verständlicherweise in der Planung schlecht umgegangen werden.
Die Frage lässt sich beantworten, in dem wir einen Blick darauf werfen, wie wir es sonst tun. Wie verlagere ich Wissen auf mehrere Schultern? Typische Wege das zu stemmen sind nicht anders als sonst auch. Hier könnte ein "Lead-Entwickler", dem das Team vertraut und der ein gutes Wissen hat, den Product Owner vertreten.
Wenn ein Unternehmen größerer ist, bestehen ggf. noch andere Möglichkeiten. Es ist aber ähnlich zu einem cross-funktionalem Entwicklungsteam. Es kostet alles einen gewissen Preis. Sie können versuchen (bei entsprechender Unternehmensgröße) eine Art Community of Practice für die Product Owner etablieren. Das funktioniert gut, wenn Sie mehrere Product Owner haben und diese zu bestimmten Teilen auch andere Produkte betreuen könnten. Das erfordert natürlich, dass Sie nicht alle Product Owner komplett auslasten und noch Verfügbarkeiten existieren.
Wie skaliere ich den Product Owner?
Skalierung bedeutet, dass wir mit mehreren Product Ownern Produkte entwickeln. In meiner 2x2 Matrix habe ich diesen Sachverhalt visualisiert. Dabei gehe ich davon aus, dass wir einen oder mehrere Product Owner haben, ebenso wie ein oder mehrere Produkte. Kaum ein Unternehmen überlegt sich zu Beginn die Herausforderungen, die mit einer Skalierung gelöst werden sollen. Es gibt ja Frameworks. Einfach einen Blueprint nehmen und dann wird das schon. Funktioniert in der Regel nicht! Wer mit Scrum auf kleiner Ebene scheitert, wird auch bei Skalierungen keinen Erfolg haben.
Zunächst einmal bin ich kein Fan, immer zur Skalierung zu greifen. Ich gestehe allen Skalierungsframeworks eine Daseinsberechtigung zu. Ob SAFe, LeSS oder Nexus, sie sind alle entstanden, da sie Herausforderungen adressieren, die in größeren Kontexten gelöst werden müssen.
Um es mit den Worten von Guy Kawasaki zu sagen "It's not about Scaling, it's about adopting". Auch wenn diese Aussage natürlich aus dem Kontext gerissen ist, steht Sie für mich bei der Skalierung recht weit vor.
Ein Produkt,
ein Product Owner
Der einfachste Fall. Sie haben genau ein Produkt und einen Product Owner. Hier benötigen Sie keine Skalierung. Der product Owner kümmert sich um sein Produkt.
Ein Produkte, mehrere Product Owner
Bei dieser Variante müssen Sie immer abwägen: schaffen Sie jetzt ein Gremium, wie es der Scrum Guide beschreibt, oder schaffen Sie so noch Mehrwert?
Mehrere Produkte, ein Product Owner
Wenn die Produkte nicht abhängig von einander sind, dann ist das ein überschaubarer Fall. Der Product Owner und die Teams entwickeln unabhängig von einander ihre Produkte.
Mehrere Produkte, mehrere Product Owner
Gibt es eine Hierarchie von Product Ownern? Dann können Sie sich in Skalierungsframeworks befinden. Im einfachsten Fall finden Sie hier Scrum of Scrums.
Weitere Beiträge zum Thema
Fazit
Der Product Owner ist eine klasse Rolle und wirklich toll, wenn die Umsetzung wie gedacht funktioniert. Es gehört allerdings eine Menge dazu, mehr als rein mechanisches Scrum zu machen. Die Organisation braucht eine klare Antwort auf das "Warum machen wir Scrum", ein passendes Training dazu, die Definition eines Produktes und eine gute Strategie, wie man sich End-2-End zum Kunden aufstellt. Das sind gute Voraussetzungen, damit auch die Product Owner Rolle gut gelebt werden kann.
[…] Backlog Item in das Sprint Planning gelangen darf. Dabei ist diese Vereinbarung zwischen dem Product Owner und dem Entwicklungsteam getroffen. Stellen wir uns diese Vereinbarung einfach als Checkliste vor, […]
[…] Sie das Backlog (das erstreckt sich bis Blatt 3). Durchnummeriert von 1-20 hängen Sie hier als Product Owner Ihre wichtigsten Product Backlog Items auf. Dazu verwenden Sie bitte die oben erwähnten großen […]