Sind Product Owner Teams eine Alternative?

Kunde: Aktuell gibt es bei uns im Haus die Diskussion, ob statt einer Person auch eine Gruppe von Personen die Product Owner Rolle übernehmen könnte. Haben Sie eine Meinung dazu?

Berater: Also, laut Scrum Guide ist der Product Owner eine Person, kein Team. Wenn Sie ein Product Owner Team einführen, ist das – laut Scrum Guide – möglich, aber kein Scrum mehr.

Kunde: Bei uns gibt es halt einerseits Leute mit der nötigen Fachkompetenz, andererseits Leute mit der nötigen Durchsetzungskraft, Entscheidungsbefugnis und Kommunikationsfähigkeit, die aber nicht die nötige Zeit und fachliche Tiefe für das Thema haben. Wäre es da nicht besser, ein Product Owner Team zu haben, um solche Differenzen auszugleichen?

Berater: Die praktische Frage ist für mich nicht, ob eine einzige Person die Product Owner Rolle haben MUSS, sondern mit welchen Risiken man zu rechnen hat, wenn ein Product Owner Team existiert.

Spontan würden mir folgende Risiken einfallen:

• Die einzelnen Personen aus einem solchen Team fühlen sich nicht selber für das Produkt verantwortlich, sie können sich „hinter der Gruppe verstecken“.
• Entscheidungsprozesse sind schwieriger und dauern in einem Team länger.
• Es entstehen höhere Abstimmungsaufwände und Informationsverluste zwischen den Entwicklern und dem Product Owner Team.
• Es gibt keinen direkten Ansprechpartner für die Entwickler.

Kunde: Das sind ja schon eine Menge Punkte. Um diese Risiken zu vermeiden, ist es für kleine Projekte also besser, nur einen einzigen Product Owner zu haben. Allerdings sind wir im letzten Jahr stark gewachsen. Die Projekte sind so komplex, dass die Aufgaben eines Product Owners nicht mehr von einer einzigen Person übernommen werden können. Gibt es im agilen Umfeld dazu schon Lösungsansätze?

Berater: Für große agile Entwicklungsprojekte hat zum Beispiel Craig Larmann das „LeSS“ Framework entwickelt. Er schlägt die Bildung von Requirements Areas vor: eine kundenorientierte Kategorisierung von Backlog Items. Für jede Area gibt es einen Area Product Owner, der für das Area Backlog (eine Sicht auf das Product Backlog) verantwortlich ist und von einem Area Team unterstützt wird. Der Product Owner und die Area Product Owner bilden das Product Owner Team. In diesem Team werden produktweite Priorisierungsentscheidungen gefällt, wobei die finale Entscheidung immer beim Product Owner liegt. Auch Scope- und Planungsentscheidungen (Releases) sind weiterhin alleinige Aufgabe des Product Owners.

Kunde: Das klingt ja schon mal vernünftig. Ich weiß nur nicht, ob das in unserem konkreten Fall wirklich so angewendet werden kann.

Berater: Agil ist, wenn man etwas ausprobiert und wieder sein lässt, wenn man merkt, daß es nicht funktioniert. Wenn man sich zu Beginn an solchen Frameworks orientiert und, auf der eigenen Erfahrung aufbauend, diese für seinen eigenen Fall modifiziert, ist das ein absolut legitimes Vorgehen.

Kunde: Vielen Dank für diesen ersten Einblick!

Diesen Beitrag haben Uwe Valentini, Bertil Muth, Jan Ebert, Dominik Angerer und Ann-Christin-Gotsch für HOOD geschrieben.