„Wir haben ein Produkt, aber mehrere Product Owner, was können wir tun?“ So lautet die mit Abstand häufigste Frage, die mir zur Skalierung von Scrum gestellt wird.
Die Ein-Product-Owner-Pro-Produkt-Regel, die wir aus Scrum mit einem Team kennen, trägt maßgeblich zur Agilität eines Unternehmens bei. Sie ist der entscheidende Schritt weg von der Projektorganisation und hin zur Produktorganisation. Der eine Product Owner fungiert in Produktorganisationen als der Ansprechpartner rund um die Zukunft des Produkts. Zusammen mit einem Product Backlog macht er die Zukunft transparent. Er verkörpert sie. Diese Einfachheit macht Organisationen beweglich.
Einfachheit bedeutet Geschwindigkeit.
Menschen, die mir diese Frage stellen, wollen genau diesen Vorteil auch für ihr Unternehmen nutzen. Sie befinden sich aber bereits in einer Situation, in welcher es schon mehrere Product Owner für ein Produkt gibt. Wenn du auch dazu gehörst, dann ist dieser Beitrag für dich. Als Steward für das Scaled Professional Scrum Training ist es meine Aufgabe, neben meiner eigenen Erfahrung mit der Skalierung von Scrum auch die Erfahrungen der weltweiten Professional Scrum Trainer Community zusammenzutragen. Dabei konnte ich viele Muster und Ähnlichkeiten beobachten und diese werde ich nutzen, um dir eine mögliche Anleitung zu geben, wie du deinem Unternehmen schrittweise helfen kannst, die Product Owner Verantwortung wieder zu einer Person dezuskalieren.
Eine häufige Ausgangssituation, in der sich Unternehmen befinden, sieht wie folgt aus:
Schritt #1: Verantwortung in der Product-Owner-Gruppe klären
Neben den einzelnen Teams, die am Produkt arbeiten, gibt es eine Gruppe von Produktverantwortlichen, häufig Produktmanager, Projektleiter, Manager, Führungskräfte oder einfach nur Product Owner.
Ich nenne sie die Product-Owner-Gruppe.
Die negativen Auswirkungen, die diese Gruppenbildung hat, sind:
- Fehlkommunikation durch unklare Aufteilung der Verantwortlichkeiten
- zeitraubende Hand-overs zwischen Mitgliedern in der Product-Owner-Gruppe
- Die Teams, die am Produkt arbeiten, werden durch diese Gruppe weiter von Anwendern und Kunden getrennt, was direkt Kommunikation und Feedback erschwert oder sogar verhindert.
Der erste Schritt, um diesen negativen Auswirkungen zu begegnen, lautet hier: Einen Product Owner benennen.
Wer ist die Person in dieser Gruppe, die letztendlich alle Entscheidungen verantwortet? Wenn es diese Person nicht gibt, dann dürft ihr nicht aufhören zu suchen. Es muss sie geben. Vielleicht befindet sie sich nur nicht in dieser Gruppe. Mein Rat lautet hier:
Folgt dem Geld.
Wer finanziert dieses Entwicklungsvorhaben? Wer könnte die Produktentwicklung abbrechen? Die Beantwortung dieser Fragen führt letztendlich immer zum wahren Verantwortlichen für den Erfolg oder Misserfolg des Produkts.
Diesen Verantwortlichen bezeichnen wir in Scrum als den Product Owner.
Ist diese Person gefunden, sollten wir herausstellen, dass es sich hierbei um den Product Owner handelt. Um seiner Verantwortung gerecht zu werden, sollte er die strategische Ausrichtung des Produkts vorgeben und verantworten. Die taktische Ausführung der Strategie kann von den anderen Mitgliedern der Gruppe übernommen werden. Um keine Verwirrung bei den Stakeholdern zu stiften, an wen sie sich in letzter Instanz wenden sollten, wenn sie Fragen zur Zukunft des Produkts haben, sollten wir die Gruppenmitglieder aber nicht Product Owner nennen. Peter Götz, ein erfahrener Professional Scrum Trainer, der schon vielen Unternehmen geholfen hat, Scrum zu skalieren, bezeichnet diesen Product Owner gerne als den Weihnachtsmann und die anderen in der Gruppe als seine Elfen. Wie wir sie bezeichnen, ist am Ende nicht wichtig. Wichtig ist hier nur die Einsicht:
Jedes Schiff hat genau einen Kapitän.
Dies gilt für kleine Einmann-Jollen, aber auch für Kreuzfahrtschiffe mit 5000 Passagieren und Crew-Mitgliedern.
Natürlich sind mit dieser Maßnahme nicht alle negativen Auswirkungen beseitigt, die Product-Owner-Gruppe existiert immer noch. Im nächsten Schritt könnten wir deshalb mehr taktische Produktverantwortung in die Teams geben.
Schritt #2: Elfen oder Proxy-Product-Owner in die Teams schicken?
Hierfür gibt es kein Patentrezept. Was ich allerdings häufig sehe, ist, dass nun jedes Team einen eigenen „Product Owner“ hat.
Und jetzt passiert der Fehler, welchen 99 % aller Unternehmen in dieser Situation machen. Sie stimmen der folgender Aussage fälschlicherweise zu:
Wenn jedes Team einen Product Owner hat, dann braucht dieser auch ein Product Backlog, welches er priorisieren kann.
Die falsche Antwort resultiert daraus, dass sie die „Product Owner“ eben nicht konsequent als Elfen bezeichnen. Die richtige Antwort muss hier lauten: Nein. Wir wollen eben nicht durch unklare Prioritäten und Abhängigkeiten, die aufgrund von mehreren Product Backlogs aufkommen, noch mehr Verwirrung stiften.
Gelingt uns dieser Schritt, dann haben wir die taktische Produktverantwortung aus der ehemaligen Product-Owner-Gruppe jetzt in die Teams verlagert. Häufig werden diese Product Owner auch als Proxy-Product-Owner bezeichnet, da sie wie ein Proxy für den wahren Product Owner fungieren. Diese Situation ist nicht ideal. Die Teilung in Proxy-Product-Owner und Product Owner liefert eine Hierarchie. Die Elfen im Team sind nicht ermächtigt, weitreichende Entscheidungen zu treffen, somit hindert diese Konstellation die Teams daran, wirklich autonome Produktteams zu werden.
Schritt #3: Themen Owner und Fachexperten ernennen
Um langfristig diese Autonomie herzustellen, braucht es zwei Dinge:
- Ein Product Backlog, welches von einem Product Owner geordnet wird und den Teams eine transparente strategische Ausrichtung vorgibt.
- Die Teams müssen echte Produktteams sein, d. h. sie müssen eine klare Nutzerfokussierung in ihrer Arbeit einnehmen.
Ein Schritt, um dies zu erreichen, kann es sein, folgendes fundamentales Gleichnis infrage zu stellen:
X Teams = X Elfen
Was wäre, wenn wir für 5 Teams nur 3 Elfen hätten? Anstatt jetzt zwei weitere Elfen zu nominieren, was ein weiterer gängiger Fehler ist, sollten wir die Chance ergreifen und alle Elfen aus den Teams lösen. Und sie eher Product-Backlog-Einträgen zuordnen.
Aus Elfen werden also Fachexperten für bestimmte Themen.
Wenn Teams bei der Verfeinerung oder Planung der Umsetzung von Product-Backlog-Einträgen Fragen haben, gibt es Ansprechpartner, die ihnen bei der Beantwortung der Fragen helfen.
Dies stellt einen großen Schritt in der Autonomie der Teams dar und gibt ihnen Freiraum, selbst Produktmanagementfähigkeiten zu entwickeln.
Schritt #4: Produktteams ermächtigen
Was unterscheidet ein Produktteam von einem Team?
Für mich zeichnet ein Produktteam neben klarem Nutzerfokus aus, dass das Produktmanagement weniger an einer einzelnen Person hängt, sondern eine Fähigkeit ist, die alle Teammitglieder besitzen. Natürlich muss nicht jeder Entwickler im Team auch ein agiler Produktmanager sein, aber er sollte langfristig ein gewisses Grundverständnis für das Produktmanagement haben. Es beginnt damit, dass er die Anwender versteht, die das Produkt verwenden. Häufig reicht es schon aus, um bei der Arbeit den Nutzer mehr in den Fokus zu rücken. Wie so häufig im Leben greift hier die 20/80-Regel.
Es reichen meist 20 % der Fähigkeiten aus, um 80 % des Ergebnisses zu erzielen.
Am Ende verhält es sich wie mit dem „Testen“. Heute stellt auch keiner mehr infrage, ob eine Fähigkeit eines Entwicklers sein sollte, dass er den Code, den er schreibt, auch testet. Mit den Anwendern zu interagieren ist genauso eine Fähigkeit und diese sollte auch nicht infrage gestellt werden. In meinem Professional Scrum mit UX Training gebe ich den Teilnehmern drei einfache Research-Techniken an die Hand: Nutzerinterview, Nutzerbeobachtung und Proto-Personas. Diese Fähigkeiten decken aus meiner Sicht schon einen Großteil der 20 % ab, die aus Teams Produktteams machen.
Damit die Wandlung vom Team zum autonomen Produktteam funktionieren kann, braucht es jetzt folgenden Mindset-Shift von Product Owner und Fachexperten:
Anstatt zu fragen „Was könnt ihr für mich tun?“ sollte jetzt die Frage gestellt werden: „Wie können wir euch helfen? Welche Fähigkeiten oder Trainings würden euch helfen?“ Die Antwort kann für jedes Team unterschiedlich ausfallen.
Die Transformation vom Team zum Produktteam ist abgeschlossen, wenn die Produktteams ihre Nutzer und Kunden so gut kennen und verstehen, dass sie in der Lage sind, das Product Backlog zu verwalten. Dass sie eigenständig Einträge erarbeiten und zum Product Backlog hinzufügen, die zur Vision oder dem aktuellen Produkt-Ziel passen. Mit einer Einschränkung:
Das Festlegen der Reihenfolge der Einträge sollte immer dem Product Owner vorbehalten bleiben.
Schritt #5: Product-Ownership als Teil des Produkts sehen
Wir haben nun autonome Produktteams, die die Einträge im Product Backlog bearbeiten, die ein Product Owner als am wichtigsten ansieht.
Irgendwann stoßen wir auch hier an Grenzen. Aus meiner Erfahrung skaliert dieses Vorgehen nicht beliebig. Auch wenn sich ein Product Owner nur auf die Priorisierung des Product Backlogs konzentriert, kommt er bei weit über 10 Teams auch hier irgendwann an kognitive Grenzen. Dieses Problem werden wir nicht mit den gleichen Denkmustern lösen, durch die es entstanden ist:
Wir skalieren die Arbeit, indem wir mehr Menschen hinzufügen und die Arbeit auf mehrere Schultern verteilen.
Dieses Denkmuster spiegelt eine veraltete Herangehensweise wider: Um mehr zu erreichen, müssen wir mehr tun. Für mich ist sie das Sinnbild der Industrialisierung. Wir befinden uns aber in dem digitalen Zeitalter. Und die Digitalisierung reißt Grenzen um uns herum ein. Das gilt auch für die Skalierung von Arbeit. Wir müssen also neue Wege gehen, um Product-Ownership zu skalieren.
Einer ist, dass wir Entscheidungen, die der Product Owner trifft, den Nutzern überlassen.
Wie geht das? Hier drei Möglichkeiten:
- Indem wir etwa in der Definition of Done festhalten, dass nur Features an alle Nutzer ausgeliefert werden, die im A/B-Test gegenüber der aktuellen Version des Produkts eine Erfolgsquote von 90 % oder mehr aufweisen.
- Indem wir den Nutzern ermöglichen, eigenständig Features freizuschalten, um somit die neue Betaversion zu testen.
- Indem wir die Kunden die Features auf der Roadmap priorisieren lassen.
Aufgaben des Product Owners zu automatisieren und als Teil des Produkts zu begreifen, muss nicht zwangsläufig der vierte Schritt sein. Ich habe ihn nur am Ende aufgezählt, denn wenn Unternehmen diesen Schritt schon früher gehen, sind häufig die anderen Schritte nicht mehr nötig.
Wenn du also deinem Unternehmen helfen willst, die Product-Owner-Verantwortung wieder auf eine Person zu deskalieren, dann liegt der Schlüssel zum Erfolg darin, die Verantwortung in einer Person zu bündeln und die Zuständigkeit der Aufgaben zu delegieren.
Möchtest Du mehr erfahren?
Hoffentlich war dieser Artikel nützlich für dich. Wie du die Product-Owner-Verantwortung deskalierst, ist eines der vielen interessanten Themen, die in meinen Professional Scrum Trainings behandelt werden.
Wenn du keinen neuen Beitrag mehr verpassen willst, dann abonniere meinen Newsletter, dort wirst du als Erster über neue Beiträge informiert.
👉 Hier geht zur Anmeldung.