Scaled Agile: Chief Product Owner (II)
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
1. 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.
1Die Gründe dafür sind nochmal ein Thema für sich, sie sind aber keineswegs immer so sinister wie es mitunter den Anschein hat.