Ein Chief Product Owner macht alles nur noch schlimmer

Nachdem Unternehmen ihre ersten erfolgreichen Schritte mit Scrum gemacht haben, beginnen sie (meist zu früh) damit, mit mehreren Scrum Teams an einem Produkt zu arbeiten. Sie möchten Scrum skalieren. Dabei wird schnell der Ruf nach einem Chief Product Owner laut, der die entstehenden Teams in irgendeiner Form organisieren soll und hierarchisch über dem Product Owner steht. Warum dieser Chief PO und seine Proxy Product Owner alles nur noch schlimmer machen und welche Nachteile durch ihn (bzw. die so erzeugte Product Owner Hierarchie) entstehen, erfährst Du in diesem Blogartikel.

Die meisten Organisationen handeln bei der Skalierung von Scrum Teams mit dem gleichen Reflex. Sie skalieren für ein und das gleiche Produkt alle Scrum Elemente und erzeugen dadurch eine Product Owner Hierarchie.

So entstehen mehrere Proxy Product Backlogs für jede einzelne (technische) Komponente eines Produktes. Diesem Proxy Product Backlog werden dann je ein Proxy Product Owner und ein oder mehrere Komponenten-Teams zugeordnet. Und um die vorherige Hierarchie der Organisation (gewollt oder ungewollt) nachzubauen, krönt man dieses Konstrukt mit einem Chief Product Owner als letzter Entscheidungsinstanz.

Der erste Grund, der für eine Hierarchie von Proxy Product Ownern und einen darüber stehenden Chief Product Owner angegeben wird, ist gleichzeitig ein Mythos. Der Scrum Guide sagt gar nicht, dass jedes Scrum Team einen eigenen Product Owner (als Person) haben muss.

Vielmehr geht es darum, dass die Verantwortlichkeit (Rolle) des Product Owners in jedem Scrum Team vorhanden sein muss.

Diese Verantwortlichkeit soll und muss in jedem Scrum Team vorhanden sein. Die Idee dahinter ist jedoch, dass ein und die gleiche Person diese Verantwortlichkeit in jedem der Scrum Teams erfüllt.

If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.

Der Scrum Guide fordert also lediglich ein Product Backlog pro Produkt. Und einen Product Owner pro Product Backlog.

Auf den ersten Blick scheint es so, dass ein Product Owner mit fünf Scrum Teams auch fünf Sprintwechsel mit jedem einzelnen Team durchführen müsste. Das liefe darauf hinaus, dass er (bei zweiwöchigen Sprints) 50 % seiner Zeit damit beschäftigt wäre, Sprint Reviews, Retrospektiven und Plannings durchzuführen. Weil das natürlich unmöglich ist, geht man davon aus, dass man mehrere Product Owner braucht, damit in jedem der Scrum Events auch stets ein Product Owner mit von der Partie ist.

Das Nexus Scrum Framework bietet einen Ausweg aus diesem Dilemma. Es transformiert Sprint Review, Retrospektive und Planning einzelner Scrum Teams zu drei “neuen” Nexus Events, was die notwendige Zahl an Scrum Events konstant hält.

Diesem Argument liegt zugrunde, dass es vor allem die Aufgabe eines Product Owners ist, Anforderungen von seinen Stakeholdern aufzunehmen, User Stories zu schreiben und den Entwicklern des Scrum Teams später gut erklären zu können. In solchen Organisationen findet sich die Rolle des Product Owners auf der Stufe des Schreiberlings, während die wirklich wichtigen Aufgaben des Product Owners (Priorisierung des Product Backlogs, Entwickeln einer Road Map und Formulierung eines Produktziels), anderweitig innerhalb der Organisation verortet sind.

Obwohl dieser Punkt stimmt, ist die Schlussfolgerung aus dieser Herausforderung falsch. Natürlich führt Komplexität dazu, dass eine Person alleine niemals das notwendige Fach- & Branchenwissen haben kann. (Genau aus diesem Grund fordert der Scrum Guide ja interdisziplinäre Teams.)

Die Schlussfolgerung, das Branchenwissen in einer Hierarchie von Product Ownern zu bündeln, in denen Proxy Product Owner einem übergeordneten Chief Product Owner zuarbeiten, führt jedoch dazu, dass dieses Fachwissen von den Entwicklern der Scrum Teams isoliert wird. (Faktisch degradiert sie das zu “Code Monkeys”, die nur noch Anforderungen umsetzen.)

Auch hier kannst Du leicht erkennen, dass man glaubt, branchenspezifisches Wissen müsse ausschließlich bei den Product Ownern vorhanden sein. Entwickler solcher Scrum Teams setzen lediglich klar formulierte Anforderungen um. Sobald jedoch inhaltliche Rückfragen auftauchen, müssen sie ihren Proxy Product Owner fragen, der dann als einziger eine Entscheidung treffen kann. Schlimmstenfalls müssen diese dann noch ihren Chief Product Owner befragen, weil sie das Thema ebenfalls nicht selbst entscheiden dürfen.

Dadurch wird die Rolle des Product Owners zum Flaschenhals für den gesamten Entwicklungsprozess. Fällt er aus (weil er zum Beispiel krank ist oder Urlaub hat), ist das restliche Scrum Team handlungsunfähig. Man begegnet dem potenziellen Flaschenhals also mit dem Aufbau zusätzlicher Silos, in denen das notwendige Wissen zu finden ist.

Zugegeben: Das ist ein unschönes Problem. Für Deine Organisation wird es jedoch immer ein Nachteil sein, sich davor zu drücken, eine Entscheidung zu treffen.

Es ist problematisch, die Struktur einer Organisationen am Vorhandensein von Menschen auszurichten.

Natürlich ist es einfacher, einen Chief Product Owner zu bestimmen und die restlichen PO zu “untergeordneten” Proxy Product Ownern zu ernennen. Letztlich wird dieses Konstrukt jedoch immer zu Problemen führen. Und damit mittel- bis langfristig mehr Schaden als Nutzen erzeugen.

Jede Organisation, die einen Chief Product Owner ernennt und ihm Proxy Product Owner unterordnet, leidet massiv unter diversen Problemen, die dadurch entstehen. (Dabei ist es übrigens auch unerheblich, ob der Chief Product Owner auch so heißt oder ob man ihn Program Manager oder dergleichen nennt.)

Der Hauptgrund all dieser Symptome liegt darin, dass die Verantwortlichkeit des Product Owners nicht skalierbar ist.

Die Hierarchie von Chief Product Owner und Proxy Product Ownern isoliert notwendiges Fach- & Branchenwissen von den Entwicklern. Ihre Aufgabe ist es vielmehr, zuvor durch diverse Product Owner ausgearbeitete User Stories korrekt umzusetzen, statt Kundenprobleme zu lösen. Am Ende mündet die Produkt Owner Hierarchie in Mikromanagement, weil Aufgaben und Probleme immer weiter zerteilt werden. Wenn sie dann die gesamte (PO-) Hierarchie durchlaufen haben, geht es nur noch darum, welcher Entwickler welche Aufgabe umsetzen wird.

Die Existenz mehrerer Product Owner macht Absprachen und Koordination notwendig, da kein einziger Proxy Product Owner Herr über sein eigenes Product Backlog ist. Auch der Chief Product Owner hat ein Backlog, in dem seine Proxy Product Owner auf den verschiedensten Ebenen die Priorisierung verändern.

Um diese Priorisierungskonflikte zu vermeiden, wird das Produkt häufig in unnatürliche Komponenten zerlegt. So erhofft man sich, möglichst wenig Abhängigkeiten erzeugen. Diese unnatürlichen Schnitte erfolgen in der Regel auf technischer Basis innerhalb des Produktes, sodass Komponenten-Backlogs entstehen.

Komponenten-Backlogs führen jedoch unweigerlich zu Komponenten Teams. Diese Teams können zwar meistens ohne allzu viele Abhängigkeiten an ihrer Komponente arbeiten. Aber sie sind nicht in der Lage, autonom Wert für Kunden und Nutzer zu stiften. Wenn sie ihre Komponente aktualisieren und erweitern, müssen andere Komponenten, die nicht bei ihnen liegen, in der Regel ebenfalls aktualisiert werden. Und dann entstehen wieder Konflikte mit der Priorisierung des Product Backlogs eines anderen Teams.

Wenn die Verantwortlichkeit zwischen mehreren Product Ownern geteilt wird, wird es für Manager solcher Organisationen schwieriger, Ansprechpartner zu identifizieren. Bei Problemen wird die Verantwortung zwischen Proxy Product Ownern und Chief PO hin und her geschoben, bis niemandem mehr klar ist, wer denn nun die Verantwortung trägt.

Um all diese Probleme und Herausforderungen zu umgehen, bietet Dir das Nexus Framework eine praktikable Lösung. Statt eines Chief Product Owners, der über mehreren Proxy Product Ownern steht, kennt Nexus weiterhin nur einen einzigen Product Owner. Er erfüllt weiterhin die Rolle des PO in jedem Scrum Team dieses Nexus. Das sorgt erstens für klare Zuständigkeiten und Verantwortlichkeiten. Zweitens ermöglicht diese Form der Skalierung weiterhin schnelle Entscheidungen. Und drittens ermöglicht es, innerhalb des Nexus mit Feature-Teams statt mit Komponenten-Teams zu arbeiten.

Der Product Owner des Nexus Frameworks ist dem Chief Product Owner in vielerlei Hinsicht sehr ähnlich. Der große Unterschied besteht jedoch darin, dass er seine Verantwortlichkeit ausübt, ohne dabei Proxy Product Owner zwischen ihn und die Scrum Teams zu schieben.

Natürlich führt das auch dazu, dass viele seiner (ursprünglichen) Aufgaben und Tätigkeiten in die Scrum Teams delegiert werden (müssen). Sie werden jedoch von Entwicklern und nicht von Proxy Product Ownern übernommen. Dieses Vorgehen fördert Selbstorganisation und Selbstmanagement der Scrum Teams insgesamt.