Mehr als ein Product Owner für ein Projekt?
Im Idealfall verwaltet in einem agilen Projekt ein Product Owner die Anforderungen und kommuniziert mit allen Stakeholdern. In den meisten Fällen reicht eine Person aus, um diese Rolle auszufüllen, und es ist sogar besser, wenn sich eine einzige Person auf die Anforderungserhebung und das Backlog-Management konzentriert, aber es gibt Fälle, in denen mehrere Personen in einem Projekt mit dieser Rolle betraut werden oder mehrere skalierte Projekte zusammenarbeiten müssen.
Wir werden uns nun mit dem ersten Fall befassen und zeigen, worauf man bei einem nicht skalierten Projekt achten muss, bei dem mehrere PO arbeiten.
Schauen wir uns zunächst die Theorie an, also das, was uns der Scrum Guide sagt:
"Oft arbeiten mehrere Scrum-Teams an demselben Produkt. Ein Product Backlog beschreibt die Arbeit, die für das zu entwickelnde Produkt zu erledigen ist." - sagt der Scrum Guide
Schauen wir uns die Empfehlungen genauer an:
"Der Product Owner ist eine Person, kein Ausschuss." - Scrum-Leitfaden
Eine Product Backlog = Ein Product OwnerDer Scrum Guide lässt dies ausdrücklich nicht zu. Es stellt sich also die Frage, warum wir einen Artikel über ein Thema schreiben, das es in der Theorie nicht gibt.
Die Praxis zeigt jedoch, dass es bei agilen Verfahren, die von Unternehmen umgesetzt werden, vorkommen kann, dass mehrere Designer als Product Owner eingesetzt werden. Wir haben Beispiele gesehen, die überraschend gut und schrecklich schlecht funktionieren.
1. getrennte Verantwortlichkeiten auf der Ebene der Product Owner
Es ist eine große Hilfe, wenn Product Owner nicht für denselben Bereich verantwortlich sind, so dass es weniger Raum für Unstimmigkeiten zwischen ihnen gibt. Wenn zwei Personen für denselben Bereich zuständig sind, sind eigentlich nicht zwei dafür verantwortlich, weil sie sich die Verantwortung teilen. Solche Bereiche können sein:
- Verantwortlich für das Geschäft
- Verantwortlich für die Einhaltung von Gesetzen
- Technische Person
- Rückstand verantwortlich
- UI / UX verantwortlich
- Testdaten verantwortlich
2. zusätzliche Rolle: Business Analyst
Sie kann besonders gut in einer Wirtschaftsanalytikerin in Teams, in denen mehrere Product Owner an der Arbeit des Teams beteiligt sind. In solchen Fällen sollte von Team zu Team entschieden werden, in welchem Umfang die Product Owner in das Leben des Teams einbezogen werden sollen.
Im Allgemeinen lohnt es sich, den Business Analysten als Proxy PO einzusetzen, um die Ungewissheit vor dem Entwicklungsteam zu verbergen, aber es lohnt sich, das gesamte Team bei den Backlog-Vorbereitungssitzungen anwesend zu haben.
3. vorbereitende Jour-fixe, der Kampf der großen Jungs
So wie Mama und Papa sich als Kinder zu Hause streiten, sind Meinungsverschiedenheiten vor dem Entwicklungsteam schädlich, da sind wir uns einig. Deshalb lohnt es sich, eine Vorbesprechung mit Product Ownern, Business Analysten und Scrum Master so dass sich die Entscheidungsträger bereits einig sind.
Vor allem wegen der kurzen Zeit, die zur Verfügung steht, lohnt es sich, eine Art Methodik für die auftauchenden Fragen zu verwenden, Farbkodierungen und Kategorien zu nutzen und die Verantwortlichen zu bestimmen, die sich vorbereiten müssen, damit du nicht ständig ein Folgetreffen organisieren musst.
4. wenn es nicht gut funktioniert, wird eine Ursachenanalyse durchgeführt
Letztendlich ist es immer wichtig, die Situation zu analysieren und herauszufinden, was die Ursache des Problems ist. Wenn du eine Ursachenanalyse durchführst und versuchst, das Problem an der Wurzel zu packen, gibt es einige sehr gute Techniken, um herauszufinden, welches Problem zuerst gelöst werden sollte. Als einfaches Beispiel können wir den Problem-Donut verwenden.
Unser Artikel geht natürlich davon aus, dass wir uns bereits in einer Situation befinden, in der mehrere Product Owner an dem Projekt arbeiten. Der beste Weg, um diese Situation zu vermeiden, ist die Arbeit mit einem PO.
Aber wenn du dich in einer nicht so idealen Situation befindest, versuche, das Beste daraus zu machen.
"Wenn du die Arbeitsweise des Teams änderst, ändere nicht mehrere Dinge auf einmal, damit du die Auswirkungen messen kannst." - Das ist unser Rat
Wenn du auf ein gutes Beispiel zu diesem Thema stößt, lass uns bitte wissen, wie das Team funktioniert und was deiner Meinung nach deine Stärken sind, die es dir ermöglicht haben, ein gut funktionierendes Team mit mehreren Product Ownern aufzubauen.