Product Ownership Evolution Model (POEM)

Viele Organisationen schaffen es nicht, die Scrum Rolle des Product Owners zur vollen Geltung zu bringen. Das liegt vor allem an zwei Dingen: Erstens haben sie eine falsche Vorstellung von der Verantwortlichkeit des Product Owners. Und zweitens sind sie es gewohnt, in Hierarchien zu denken. Beides zusammen genommen erzeugt häufig eine üble Mischung. Zwei Tools helfen Dir und Deiner Organisation, ein besseres Verständnis von den Aufgaben des Product Owners zu entwickeln und diese Herausforderung zu meistern: Die Product Owner Maturity Level und das Product Ownership Evolution Model von Tim Klein & Oliver Winter.

Mit den Product Owner Maturity Leveln lassen sich Reifegrade der Product-Owner-Rolle darstellen, die eine Organisation in ihrem Bestreben, agil zu werden, bisher erreicht hat.

Auf der ersten Stufe der Product Owner Maturity Level ist der PO vor allem derjenige, der innerhalb der Organisation die verschiedensten Anforderungen aus allen möglichen Abteilungen aufnimmt. Als Scribe hat er wenig bis keine Autorität über sein Product Backlog, sondern ist vielmehr nur derjenige, der User Stories schreiben soll und dafür sorgt, dass die Entwickler die Anforderungen verstehen. Die Backlog Priorisierung selbst erfolgt jedoch durch andere Positionen bzw. Personen im Unternehmen.

Der Proxy Product Owner besitzt bereits ein wenig mehr Autorität als der Scribe. Er kann (begrenzte) Entscheidungen über die Priorisierung im Backlog treffen. Häufig wird er jedoch durch “höhere Instanzen” wie Abteilungsleiter oder Geschäftsführer überstimmt. Seine (undankbare) Aufgabe ist es, aus diesem Netz von Wünschen und Bedarfen eine hübsche Reihenfolge zu machen und alles so zu erledigen, dass möglichst alle zufrieden sind. (Was naturgemäß scheitert.)

Die Verantwortung für die Entwicklung einer Produktvision, eines Produktziels oder zu erreichender Ergebnisse ist jedoch weiterhin anderweitig in der Organisation verortet. In seiner Rolle ist der Proxy Product Owner also lediglich ein Stellvertreter (Proxy), weil die eigentliche Verantwortung für das Produkt bei anderen liegt. Wenn der Proxy Product Owner Dinge im Product Backlog umsortieren oder die Priorisierung verändern will, muss er typischerweise um Erlaubnis fragen oder zumindest Rücksprache halten.

Die dritte Evolutionsstufe des Product Owners ist der Business Representative. Häufig sind diese Product Owner eher auf der Geschäftsseite einer Organisation zu verorten statt auf der rein technischen Seite. Der Business Representative ist gut mit Kunden und Nutzern vernetzt . Deshalb hat er ein gutes Verständnis davon, was der Markt benötigt.

Er hat bereits viel Hoheit über sein Product Backlog und kann (meistens) autonom über dessen Priorisierung entscheiden. Allerdings kann er das nur im Rahmen der ihm zur Verfügung stehenden Mittel tun, weil er keine Budgetverantwortung besitzt. Soll das Budget angepasst werden, benötigt der Business Representative die Einwilligung des Managements.

Typischerweise hat der Product Owner auf dieser Evolutionsstufe eine Liste von Arbeit, Projekten und Zielen, die er erreichen muss, die ihm jedoch andere vorgegeben haben.

Der große Unterschied zum Business Representative besteht darin, dass der Sponsor ein eigenes Budget besitzt. Bevor ein Product Owner diesen Reifegrad erklommen hat, liegt die Budgetverantwortung üblicherweise anderweitig innerhalb der Organisation. Das hindert den Product Owner jedoch daran, die Anzahl der Scrum Teams zu verändern. (Falls er beispielsweise der Meinung ist, die Produktentwicklung müsse beschleunigt oder verlangsamt werden.)

Die höchste Stufe der Product Owner Maturity Level ist die Stufe des Entrepreneurs oder Mini CEO. Dieser Product Owner hat wirklich die volle Produktverantwortung und stiftet für Kunden, Nutzer und seine Organisation den maximalen Nutzen. Dazu benötigt er natürlich ausgeprägte Leadership Skills und eine starke Produktvision, damit er für seine Teams ein echter Kristallisationskern werden kann.

Darüber hinaus sind Entrepreneure nicht nur für die Produktentwicklung zuständig, sondern auch für Wartung, Betrieb, Marketing oder gesetzliche Aspekte ihres Produktes. Auch der Vertrieb des Produktes liegt innerhalb seiner Verantwortung. (Im Sinne von Accountability.)

Für sich allein genommen sind die Product Owner Maturity Level zwar erhellend, aber noch nicht wirklich praktikabel. Hier kann Euch das Product Ownership Evolution Model (POEM) von Tim Klein und Oliver Winter weiterhelfen.

Das Product Ownership Evolution Model bringt die oben vorgestellten Reifegrade der Product-Owner-Rolle in eine aufeinander aufbauende Reihenfolge. (In der Original-Vorlage von Tim & Oliver sind die Maturity Level leider nicht eingezeichnet, weshalb ich sie hier für Dich ergänzt habe.)

Das POEM beginnt auf der linken Seite mit den strategischen Verantwortlichkeiten. Je weiter sich die Aufgaben nach rechts bewegen, desto taktischer werden sie, bis auf der ganz rechten Seite die operativen Aufgaben zu finden sind.

Zunächst platziert Ihr gemeinsam die Rolle des Product Owners auf der Leiste für den IST-Zustand. Und zwar genau dort, wo er noch vollkommen autonom entscheiden kann, ohne andere um Erlaubnis zu fragen oder noch Rücksprache mit anderen halten zu müssen.

Das Gleiche wiederholt Ihr für die Entwickler des Scrum Teams. Auch sie platziert Ihr im Product Ownership Evolution Model in dem Aufgabenfeld, bei dem sie derzeit ohne Rücksprache mit ihrem Product Owner entscheiden können.

Im dritten Schritt platziert Ihr den Business Owner (BO). Der Business Owner ist diejenige Person, die den Product Owner ermächtigt, seinen Aufgabe zu erfüllen. Der BO wird also ein Abteilungsleiter, Geschäftsführer oder dergleichen sein. Auch ihn setzt Ihr in das Aufgabenfeld, bei dem der Business Owner noch vollkommen autonom entscheiden kann.

Die Entwickler des Scrum Teams dürfen (vorhandene) Product Backlog Items weiter ausarbeiten, konkretisieren und umsetzen. Die Product Backlog Items selbst werden jedoch nur in Absprache mit dem Product Owner erstellt.

Nachdem Ihr den IST-Zustand im Product Owner Model visualisiert habt, definiert Ihr nun gemeinsam den gewünschten SOLL-Zustand. Das Ganze erfolgt in der gleichen Reihenfolge wie beim IST-Zustand. Erst wird der PO gesetzt, dann die Entwickler, dann der Business Owner.

Hier wird es in der Regel spannend, da nun die individuell anstrebten Zielzustände sichtbar werden, die zuvor nur in den einzelnen Köpfen existierten. Erfahrungsgemäß wird in dieser Phase sichtbar, dass die Vorstellungen davon, “wo die Reise hingehen soll”, mitunter weit auseinander gehen.

Das Gute daran ist, dass Ihr nun darüber sprechen und Euch gemeinsam auf einen Zielzustand einigen könnt. (Auch dieser muss ja nicht gleich der Weisheit letzter Schluss sein, sondern ein erster Schritt in Richtung Mini CEO.)

Im Bereich Coaching-Angebot markiert Ihr, welche Angebote des Scrum Masters bereits für Entwickler und Product Owner existieren. Im Bereich Coaching-Bedarf haltet Ihr hingegen Angebote fest, die Product Owner, Entwickler und Business Owner benötigen, um ihre zukünftigen Aufgabenbereiche erfüllen zu können.

Damit Du eine konkretere Vorstellung davon erhältst, wie ein fertig ausgefülltes Product Ownership Evolution Model aussieht, habe ich hier einmal ein Beispiel für Dich aufgeführt.

Aus dem SOLL-Zustand kannst Du als Scrum Master gemeinsam mit Deinem Product Owner ableiten, welche konkreten Coaching-Angebote er benötigt, um seine neuen Aufgabenfelder erfolgreich zu bewältigen.

Ich hoffe, ich konnte Dir den Nutzen beider Tools ein wenig näher bringen. Solltest Du noch Fragen zu den Product Owner Maturity Leveln oder zum Product Ownership Evolution Model haben, schreib mir gerne einen Kommentar hier unten auf der Seite! Ich helfe gerne weiter.