Scaled Agile: Chief Product Owner
Bild: Flickr / Rod Waddington - CC BY-SA 2.0 |
Wenn Teams nach Scrum arbeiten gilt in Bezug auf die Rolle des Product Owners das Highlander-Prinzip: Es kann nur einen geben. Der Scrum Guide formuliert das an gleich zwei Stellen sehr eindeutig: "For Product Owners to succeed, the entire organization must respect their decisions." und "The Product Owner is one person, not a committee." Für ein einzelnes Team ist das auch nachvollziehbar, aber was passiert wenn mehrere Teams zusammenarbeiten müssen? Einen Ansatz findet man in diesem Kontext immer wieder.
Passend zum teamübergreifenden Konstrukt des Tribes findet man in vielen Organisationen die Rolle des Chief Product Owners oder CPO (auch Head PO, Lead PO, o.ä.), der hierarchisch oberhalb der eigentlichen Product Owner angesiedelt ist. Wie diese Rolle aussieht wenn sie mit Scrum kollidiert wäre ein eigenes Thema, bezogen auf "Scrum by the Book" gibt es aber die klare Grenze, dass der eigentliche Product Owner nicht in seinen Kompetenzen eingeschränkt werden darf. Die spannende Frage: ist das überhaupt möglich? Welcher Spielraum bliebe noch für eine zusätzliche Rolle?
Eine Möglichkeit wäre diese: Das Produktmanagement-Themenfeld das der Scrum Guide für höhere Ebenen zugänglich hält ist die initiale Auswahl, bzw. Definition der Produkte, verbunden mit dem Setzen der Produktziele. Es heisst zwar "The Product Owner is [...] accountable for effective Product Backlog management, which includes: Developing and explicitly communicating the Product Goal.", aber das Entwickeln und Kommunizieren eines Produktziels ist eben etwas anderes als dessen Auswahl. Ein CPO kann also Produkte und deren Ziele (vor)auswählen, um sie dann den POs und deren Teams zu übergeben.
Was in Scrum explizit nicht zum Aufgabenbereich eines CPO gehören kann ist im Anschluss daran die Arbeit an den Backlogs, er soll also weder eine Ausdetaillierung der Backlog Items vornehmen noch spezifische Arbeitsaufträge an die Teams vergeben oder deren Reihenfolge oder Priorität festlegen. Das bleibt dem PO vorbehalten, der dafür auch Teil mehrerer Scrumteams sein kann (was so seit 2020 auch explizit im Scrum Guide steht und nicht mehr implizit daraus abgeleitet werden muss).
Diese Aufteilung in CPO (ausserhalb des eigentlichen Scrum) und PO (offizieller Teil von Scrum) kann in der Anwendung schnell künstlich wirken und im schlimmsten Fall zu Konflikten führen, durch die Ressourcen gebunden und die Organisation gelähmt werden. Im Rahmen des Scrum-Frameworks ist es aber die einzige mögliche Aufteilung. Das heisst zwar nicht, dass man nicht alles anders organisieren könnte - aber dann ist es kein Scrum mehr.
Nachtrag 26.02.:
Eine Übersicht über andere Interpretationen der Chief PO-Rolle gibt es hier.