Der Product Owner im Detail (kennen Sie die?)

Der Product Owner

Scrum Product OwnerDer Product Owner ist eine der drei Rollen im agilen Projektmanagement Framework Scrum. Neben den beiden Rollen Scrum Master und Entwicklungsteam, kümmert sich der Product Owner um die Anforderungen im Projekt. Ihm gehört das Product Backlog, 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 Effektivität 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 Aufgaben

Der Product Owner hat diverse Verantwortlichkeiten und Aufgaben, denen er in seiner Rolle gerecht werden muss. Und das ist gar nicht so leicht! 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 („was“) des Produktes maßgeblich mit bestimmen. Er ist derjenige, der mit dem Kunden die Wünsche erarbeiten muss. 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. Am Ende eines Sprints ist er es, der die Product Backlog Einträge abnimmt (übrigens: es muss nicht immer das Ende des Sprints sein, es ist nur der letztmögliche Punkt!)

Der Product Owner denkt immer visionär und unternehmerisch. Er besitzt die Produktverantwortung und sollte 50-80% seiner Zeit für ein Projekt und Team aufwenden können. Er sitzt optimal im Teambereich oder ist greifbar, 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.

Einer der Scrum Werte ist Mut – diesen muss Product Owner selbstverständlich aufbringen (können), denn ab und zu müssen Backlogeinträge weggeworfen, mit dem Kunden die Reihenfolge diskutiert oder ganz unkonventionelle Wege eingeschlagen werden.

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 klassisch 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. Diese Faktoren sind mit Sicherheit meine subjektiven Eindrücke und auch keine Szenarien die ich empfehle oder für gut betrachte. Es sind einfach Erlebnisse und Eindrücke, die ich teile.

Unternehmensgröße

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.

Produktinkrement in Scrum

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.

Eine Ursache liegt oft hier begraben…

Scrum Entwicklungsteam

Die Größe von Unternehmen korreliert in meinen Augen sehr stark damit, ob ein Entwicklungsteam 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 Funktionen zu denken, nicht aber im Sinne eines Produktes, das in einem Backlog beschrieben wird und von einem Team umgesetzt wird. (Und ja: ich weiß selbst, dass nicht ein Team ein Auto, einen Roboter oder ein wie auch immer geartetes System liefern kann – darum geht es primär auch nicht!)

Genug philosophiert, nun geht es an die Punkte, die ich vom Treffen mitgenommen und mir noch mal durch den Kopf habe gehen lassen.

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’s roles, artifacts, events, and rules are immutable and although implementing only parts of Scrum is possible, the result is not Scrum.

Scrum Guide

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ößer 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 Onwer 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?

Zunächst einmal bin ich kein Fan, alles gleich über eine Skalierung zu lösen. 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.

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.

Warum wollen oder müssen wir den Product Owner denn überhaupt skalieren? Dabei gibt es zwei Ansätze. Zum einen können Sie über die Produkte skalieren. Sie haben also mehrere Produkte und benötigen deshalb auch mehrere Product Owner. Das ist oft der Aspekt, den viele nicht unter der typischen Skalierung verstehen. Der zweite Ansatz geht über das selbe Produkt. Ich will es einmal recht einfach ausdrücken: das Produkt ist groß und kann nicht von einem Product Owner alleine verwaltet werden.

product-owner-skalierung

Sowas sollte aus meiner Sicht emergent wachsen und durch die Organisation selbst entwickelt werden. Je weniger reif die Organisation ist, desto besser funktionieren Frameworks – zumindest von der Überzeugung diese einzuführen.

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.

Leave a Reply 6 comments

Was ist Scrum? (und was ist es eben nicht!) - Online Scrum Kurse - 11 months ago Reply

[…] kennt drei Rollen: den Scrum Master, den Product Owner und das Entwicklungsteam. Dazu kommen drei Artefakte, nämlich das Product Backlog, das Sprint […]

Das Sprint Planning in Scrum - Online Scrum Kurse - 11 months ago Reply

[…] der kommende Sprint geplant wird. Es teilt sich in der Regel in zwei Teile auf. Im ersten gibt der Product Owner an, was er gerne hätte. Im zweiten Teil bestimmt das Entwicklungsteam, wie es sich eine Umsetzung […]

Das Sprint Review als Lernevent! - Online Scrum Kurse - 7 months ago Reply

[…] Product Owner ist die Person, die zu diesem Meeting einladen sollte. Oft übernimmt so etwas der Scrum Master. […]

Priorisierung der Stories im Sprint? - Online Scrum Kurse - a few months ago Reply

[…] der Product Owner im Sprint Planning 1 vorstellt, WAS er gerne hätte, sagt das Team im Sprint Planning 2, WIE es die […]

Kontinuierliche Verbesserung: die Retrospektive - Online Scrum Kurse - a few months ago Reply

[…] wird immer über die Teilnahme des Product Owners bei der Retrospektive diskutiert. Ich persönlich finde es unter bestimmten Bedingungen gut, wenn […]

So verbessern Sie Ihr Backlog Refinement - Online Scrum Kurse - a few months ago Reply

[…] um in der Sprint Planung sinnvoll prozesiert werden zu können. Das Entwicklungsteam und der Product Owner haben hier die Möglichkeit das Verständnis zu schärfen: sie detallieren Anforderung, schätzen […]

Leave a Reply:







Verbessere dein Projektmanagement. Mit Scrum.

x