Montag, 4. Dezember 2017

Scaled Agile: Chief Product Owner

FS
Bild: Flickr / Rod Waddington - CC BY-SA
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: "The Product Owner is the sole person responsible for managing the Product Backlog." 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 an einem gemeinsamen Produkt arbeiten?

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 die übergreifende Produktvision verantworten soll. Er gibt damit das Fernziel vor, das erreicht werden soll und aus der die Product Owner nach dem Pull-Prinzip die Arbeit der Teams ableiten können. Diese Konstellation ist im Rahmen des Frameworks zulässig, da die Vision zwar erwähnt wird, aber nicht festgelegt ist, wer ihr Owner ist. Es kann also auch jemand anderes als der PO sein. Wie aus ihr allerdings konkrete Arbeit (an einem Increment) abgeleitet wird liegt sehr wohl bei ihm.

Was explizit nicht zum Aufgabenbereich des CPO gehören kann ist die Arbeit an den Backlogs, er soll also weder Arbeitsaufträge an die Teams vergeben noch deren Reihenfolge oder Priorität festlegen. Das bleibt dem PO vorbehalten, der dafür auch Teil mehrerer Scrumteams sein kann. Dass lässt sich indirekt aus dem Scrum Guide ableiten, der zum einen festlegt, dass nur der PO das Backlog verantwortet, zum anderen aber auch, dass mehrere Teams aus einem Backlog arbeiten können.

Diese Aufteilung in CPO (Produktvision) und PO (Product Backlog) 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.

0 comments:

Kommentar veröffentlichen

Powered by Blogger.