Bei unserer Arbeit beim und mit dem Kunden beobachten wir bei der Rolle des Product Owners (PO) immer wieder ein Spannungsfeld. Zum einen ist dies der Art und Weise geschuldet, wie die Rolle des Product Owners rekrutiert wird. Zum anderen wie agile Frameworks (wie Scrum und SAFe) eingeführt werden.
Rekrutierung der Product Owner
Bei der Rekrutierung der Product Owner Rolle stellt sich initial die Frage, wie diese Positioniert sein soll. Veranschaulichen lässt sich dies anhand folgender Matrix:
Abbildung: eigene Darstellung, Quelle: scrum.org
Bei den meisten Unternehmen ist eine eher fachliche Ausrichtung angestrebt. Der Grund dafür ist, dass mit dem Produkt direkt der Anwender angesprochen wird. Der Product Owner sollte also ein hohes Verständnis für die Tätigkeiten des Anwenders mitbringen. Eine technische Ausrichtung kommt zum Zuge, wenn das Produkt eher den Charakter eines Enablers hat. Zum Beispiel ein Datenbank Framework wie SQL oder Oracle. In diesem Fall sind wir die Hersteller des Frameworks und nicht wie sonst üblich die Nutzer. Für was die Datenbank später eingesetzt wird ist für uns weniger im Fokus. Eine reibungslose, technische Funktion dafür um so mehr.
Randbemerkung: Ein Ziel von Scrum und SAFe ist es, in den Organisationen das “Fach” und die “IT” zu einer engeren Zusammenarbeit zu bewegen. Bei der Suche nach einem fachlichen Product Owner wird dieser oft “im Fach” rekrutiert. Dabei können wir beobachten, dass die Organisation diese Rekrutierung “im Fach” gleichsetzt mit der angestrebten, engeren Zusammenarbeit zwischen “Fach” und “IT”. Dies mag vielleicht als erster Schritt durchaus anstrebenswert sein, bringt der Organisation oft aber nur ein kurzfristiges “Näherrücken”.
Bei der Positionierung auf der horizontalen Achse Spielt nun das agile Framework und wie es gelebt wird eine wichtige Rolle.
-
Gibt es ein “klassisches” Produktmanagement?
-
Arbeiten mehrere Scrum Teams am selben Produkt?
-
Falls ja, wie viele Scrum Teams sind es?
-
Wird ein skaliertes, agiles Framework verwendet?
-
Falls ja, welches (z.B. SAFe, Nexus, LeSS usw.)?
An dieser Stelle wollen wir nun die Überleitung zum nächsten Grund für die Spannungsfelder machen.
Einführung agiler Frameworks
Basierend auf unseren Erfahrungen sind wir oft mit der Tatsache konfrontiert, dass ein Unternehmen, welches uns für die Einführung von SAFe anfragt, meist nur geringe Erfahrungen mit Scrum hat. Da ein gutes methodisches Fundament wichtig ist, um darauf skalieren zu können, befähigen wir die Teams als erstes in Scrum. Wenn wir im Beispiel davon ausgehen, dass das Unternehmen noch nicht nach Scrum arbeitet, wird es rasch mit der Frage konfrontiert sein, wer Product Owner wird. Orientiert sich nun die Rekrutierung aber zu stark an der Beschreibung des Product Owners von Scrum, kann dies dazu führen, dass den Kandidaten die Rolle des Product Owner “schmackhafter” gemacht wird, als dies bei der späteren Skalierung der Fall sein dürfte. Bei der initialen Formulierungen* der Verantwortung des Product Owners liesst man dann:
-
Der Product Owner gestaltet, wie sich das Produkt weiterentwickeln soll → Product Vision & Roadmap
-
Der Product Owner entscheidet, was das Dev.-Team umsetzen soll → Priorisierung
-
Der Product Owner stellt sicher, dass das Dev.-Team versteht, was zu tun ist → Product Backlog; User Stories
Findet sich der Product Owner aber nach der Einführung von SAFe in einem Agile Release Train wieder, so hat sich seine Rolle doch in diesen Punkten geändert. Betrachten wir uns mal die drei Verantwortungen aus der Auflistung. Da bei den ersten beiden Verantwortungen entscheidend ist, was für uns das Produkt ist und wie die Teams aufgeteilt sind (Component vs. Feature Teams), gehen wir von folgendem Szenario aus:
-
Alle Teams arbeiten auf ein gemeinsames Produkt hin
-
Die Teams sind Component und Feature Teams
-
Die Teams können untereinander wenig aushelfen
Product Vision & Roadmap
Der Name Product Owner ist in SAFe etwas verwirrend. Der Grund für eine Skalierung ist ja oft, dass mehrere Teams gemeinsam an einem Produkt arbeiten. Der Product Owner wird also weniger für das Produkt als solches, sondern für einen Funktionsbereich (Feature Team) oder eine Komponente (Component Team) des Produkts verantwortlich sein. Seine Fokus ist also vor allem darin, das Scrum Team mit “Futter” (User Stories) zu versorgen.
Bei der Product Vision und der Plannung der Roadmap wird er also mehr als Stakeholder involviert sein und weniger im Lead. Der Lead ist beim Product Management (PM) gemäss Rolle von SAFe.
Priorisierung
Ähnlich wie bei der Product Vision und der Roadmap ist auch bei der Priorisierung (des Produkts) das Product Management im Lead. Der Product Owner ist aber zum Beispiel verantwortlich die Team Ressourcen und die vom Product Management definierten Priorisierungen in einen best möglichen Einklang zu bringen.
Scrum Guide: “The Product Owner is accountable for maximizing the value of the product resulting from the work of the Scrum Team.”
Backlog, User Stories
Was die Pflege des Product Backlogs und das Formulieren von User Stories angeht, haben Scrum und SAFe das selbe Verständnis betreffend der Rolle des Product Owners. Es bleibt dem Product Owner überlassen, ob er teile davon delegieren will oder es selbst macht. Er bleibt aber in beiden Fällen rechenschaftspflichtig dafür.
Scrum Guide: “The Product Owner is also accountable for effective Product Backlog management, …”
Schlussbemerkung
Wie wir gesehen haben ändert sich die Rolle des Product Owners gerade im Bezug auf strategischere Fragen, resp. Verantwortungen. Es lohnt sich also hier bereits zu Beginn der Einführung von SAFe Klarheit darüber zu schaffen, welche Erwartungen bei diesen Punkten an die Rolle des Product Owners gestellt werden. Immerhin dürfte für viele Kandidaten gerade diese Aufgaben die Rolle des Product Owner interessant machen.
* Die drei Formulierungen sind an der Stelle nur als positiv und negativ Beispiele zu verstehen und entbehren sich allgemeiner Gültigkeit und/oder Vollständigkeit