Scaled Agile: Chief Product Owner (II)

Bild: Wikimedia Commons / Fredrick W. Glasier - Public Domain

Spätestens mit dem Scrum@Scale-Guide ist die Frage noch einmal aktuell geworden wie die Rolle eines Chief Product Owner (oder Lead PO, Head PO, etc.) definiert ist. Die Diskussion ist in sofern von Bedeutung, da der Chief PO eines der klassischen Einfalltore ist, über das vom mittleren Management versucht werden kann die Autonomie und Selbstorganisation der Scrum Teams auszuhebeln¹. Es lohnt sich also ein Blick auf die verschiedenen Ausgestaltungen.

Der Scrum-kompatible Chief PO

[Edit: durch das Scrum Guide-Update 2020 wurde eine Aktualisierung dieses Absatzes nötig]
Gleichzeitig die Scrum-kompatibelste und die mit klassischem Managementverständnis am wenigsten kompatible Ausgestaltung. Auf der strategischen Ebene für die initiale Auswahl von Produkten und Produktzielen zuständig gibt ein Scrum-kompatibler Chief PO den eigentlichen Product Ownern lediglich ein abstraktes Ziel vor, das sie nach eigenem Ermessen in Produkte umwandeln können. Er füllt damit eine der Lücken aus die Scrum bewusst freigelassen hat um individuelle Lösungen zu ermöglichen. Um die Product Ownerships der Teams nicht zu untergraben ist in Richtung der POs im weiteren Verlauf nur Reflektion und Feedback möglich, keine Anweisung. Das erfordert von allen Beteiligten einen hohen Reifegrad und hohe Professionalität.

Der LeSS/Nexus-Product Owner

Im Grunde kein Chief Product Owner im eigentlichen Sinn, da es keine weiteren Product Owner ausser ihm gibt. Im LeSS-Skalierungsframework kann eine Person Product Owner mehrerer Teams sein, die diese Mehrfachbelastung dadurch ausgleichen, dass sie ihn unterstützen (gleiches gilt im ähnlichen Nexus-Framework). Dabei können in den Teams PO-ähnliche Rollen entstehen, allerdings ohne die damit verbundenen finalen Entscheidungskompetenzen. Diese Konstellation lässt sich auch aus dem Scrum Guide ableiten, der einerseits klarstellt, dass der PO die einzige für das Backlog-Management zuständige Person ist, andererseits aber zulässt, dass mehrere Teams ein gemeinsames Backlog haben.

Der Risikokapital-Investor

Ein Typ der eher in ein Startup-Umfeld passt. Die eigentlichen POs sind zwar frei in der Entscheidung was sie in ihren Backlogs haben und wie diese priorisiert werden, sie müssen mit ihren Produktideen allerdings in einen Pitch bei ihrem Chief-PO gehen, der dann entscheidet ob er diese Ideen finanziert oder nicht. Um (auch nur versehentliches) Micromanagement zu vermeiden sollten diese Finanzierungen jeweils für einen längeren Zeitraum vorgenommen werden, z.B. für zehn Sprints.

Der Scrum@Scale Chief Product Owner / Epic Owner

Die erste problematische Rollendefinition. Im Scrum@Scale-Framework wird der Chief PO so beschrieben, dass er ein übergreifendes Backlog definiert, dessen Einträge aber zu groß sind um in Sprints umgesetzt zu werden. Um das möglich zu machen werden sie von den eigentlichen POs in kleinere Arbeitspakete zerteilt. Da diese zu großen Aufgaben der gängigen Definition eines Epic entsprechen (eine Anforderung die zu groß für einen Sprint ist) ist in manchen Unternehmen auch der Begriff des Epic Owners üblich. Schwierig ist das, weil es die Scrum Teams sehr stark in ihrer Product Ownership einengen kann wenn ihnen auf höherer Ebene Vorgaben gemacht werden. Bei sehr großen Aufgaben/Epics kann das zwar irgendwie funktionieren, die Wahrscheinlichkeit von Dysfunktionalitäten ist aber sehr hoch.

Der SAFe-Product Manager / Solution Manager

Ebenfalls problematisch. Im Scaled agile Framework (SAFe) wird unterschieden zwischen dem Product Owner, zuständig für Technologie und Team und dem ihm übergreordneten Product Manager, zuständig für Markt- und Kundenkontakt. Gegebenenfalls befindet sich als weitere Ebene darüber noch der Solution Manager. Das passt zwar sehr gut mit klassischen Unternehmensstrukturen zusammen, macht aber einen der zentralen Vorteile von Scrum rückgängig, die enge Zusammenarbeit zwischen dem Kunden/Benutzer und dem Umsetzungsteam.

Der Cargo Cult Chief PO

Leider viel zu häufig anzutreffen - ein direkter Vorgesetzter der einzelnen Product Owner, der ihnen Anweisungen geben und Micromanagement durchführen kann. Führt sehr schnell zu Reporting-Overhead, Bürokratie und Ineffizienz. Wie gesagt, Cargo Cult.

---

Im Einzelfall finden sich noch zahlreiche weitere Variationen, die wichtigen Typen sind aber hier erfasst. Grundsätzlich gilt aber beim Product Owner das gleiche wie für agile (und nicht-agile) Produktentwicklung im Ganzen: Skalierung macht Strukturen zwar größer aber nicht notwendigerweise leistungsfähiger. Man sollte sich also gut überlegen ob man sie wirklich braucht.


¹Die Gründe dafür sind nochmal ein Thema für sich, sie sind aber keineswegs immer so sinister wie es mitunter den Anschein hat.