Skalierung von Scrum: 3 Prinzipien von erfahrenen Product Ownern
Anna ist Product Ownerin der erfolgreichen E-Commerce-Plattform "Unvergessliche Kindergeburtstage". Wie viele andere Produkt-Manager steht sie vor der Herausforderung, Kunden- und Marktanforderungen noch vor der Konkurrenz umzusetzen: "Wir arbeiten in einem sehr wettbewerbsorientierten und schnelllebigen Markt, nach anfänglichem Erfolg haben wir uns entschieden, unsere Entwicklung mit 3 weiteren Scrum-Teams zu verstärken, um gegenüber unserer starken Konkurrenz nicht ins Hintertreffen zu geraten."
Seitdem Anna für 4 Teams zuständig ist, ist sie überfordert, da sie mit ihrer Arbeit hinterherhinkt. Es ist nie genug Arbeit für die Teams spezifiziert und bei der Abnahme der Stories müssen die Teams ständig auf sie warten. Sie hat den Eindruck, dass sie die Teams ausbremst. Als sie von einem Berater hört, dass jedes Scrum-Team einen Product Owner braucht, sieht sie das als ihre Rettung an und stellt drei junge Product Owner ein.
Was ihr als Rettungsanker verkauft wurde, stellte sich schnell als ein noch größeres Problem heraus: "Das Fingerspitzengefühl und die Erfahrung, welche man braucht, um alle Wünsche der Stakeholder unter einen Hut zu bekommen, fehlt den neuen Product Ownern einfach ganz. Seit den Einstellungen verbringe ich die meiste Zeit damit, die Neuen einzuweisen und zu unterrichten."
Auch die Teams sind unzufrieden, da die Product Owner nicht schnell Antworten auf ihre Fragen liefern können. Abhilfe sollten die Team-Backlogs schaffen. Aber diese Backlogs mit dem "echten" Backlog und der Roadmap zu synchronisieren, bereitet Anna nur noch mehr Koordinationsaufwand.
Kommt dir das bekannt vor? Wahrscheinlich schon – aus meiner eigenen Arbeit als Product Owner und meiner Unterstützung von Product Ownern weiß ich, dass viele vor Annas Herausforderung stehen. Darüber hinaus ist auch die Frage, wie Scrum effektiv skaliert wird, eine der häufigsten in meinen Professional Scrum Trainings. Annas Situation untermauert die Notwendigkeit des ersten Prinzips bei der Skalierung von Scrum:
Vertraue dem Highlander-Prinzip, um Abstimmungsprobleme zu vermeiden
Wenn wir Annas Situation analysieren, dann erkennen wir, dass mehrere Product Owner und Team Backlogs weitere Kommunikationswege bedeuten. Wenn die Anzahl der Kommunikationspfade steigt, steigt die Komplexität. Um diese zusätzliche Komplexität in den Griff zu bekommen, sind weitere Abstimmungen nötig. Denn damit gute Entscheidungen in einer Gruppe getroffen werden können, müssen sich alle Beteiligten einbringen können. Diese Art der Entscheidungsfindung dauert zwangsläufig länger und führt zu einem Wettbewerbsnachteil gegenüber der Konkurrenz, wie eine Umfrage von McKinsey unter 1.400 Führungskräften aus verschiedenen Branchen, Regionen und Eigentümerstrukturen ergab [1]. Aufgrund langsamer getroffenen Entscheidungen ist die Reaktion auf sich ergebende Veränderungen drastisch erschwert und Investitionschancen können schlechter genutzt werden.
Product Owner: Es kann nur einen geben.
Um Scrum effektiv zu skalieren, sodass weiterhin ein schneller Kurswechsel möglich ist, um jederzeit sich bietende Marktchancen zu ergreifen, berücksichtigen erfolgreiche Product Owner das Highlander-Prinzip: Pro Produkt nur ein Product Owner und ein Product Backlog. Damit halten sie sich an die Vorgabe im Scrum Guide: Der Product Owner ist ergebnisverantwortlich für die Maximierung des Wertes des Produkts, der sich aus der Arbeit des Scrum-Teams ergibt.
Sie skalieren dabei ihre Verantwortung für das Produkt nicht durch mehrere Personen, sondern durch Erweiterung des Scrum-Teams um Produktmanagement-Fähigkeiten, damit diese autonomer, kompetenter und selbstorganisierter werden.
Das Stichwort lautet: Delegieren. Und findet sich auch als Vorschlag im Scrum Guide: Der Product Owner kann die […] Arbeiten selbst durchführen oder die Umsetzungsverantwortung an andere delegieren.
Product Owner stärken die Produktmanagement-Fähigkeiten ihrer Scrum-Teams, indem sie
- ständig ihr Wissen über den Kunden, Benutzer, Markt und Domäne an die Entwickler in Refinements und Sprint Reviews weitergeben,
- sicherstellen, dass es eine direkte Kommunikation und ein direktes Feedback zwischen Kunden, Nutzern und den Entwicklern gibt,
- dafür sorgen, dass die Produktvision und -strategie allen klar ist, das heißt, die Vision des Produkts wird am Anfang jedes Scrum Events herausgearbeitet,
- eine Roadmap basierend auf den zukünftigen Zielen für das Produkt erstellen und diese regelmäßig im Sprint Review und Sprint Planning vorstellen,
- gewährleisten, dass das Product Backlog klar, geordnet, sichtbar, transparent und für alle Beteiligten und Entwickler zugänglich ist.
- regelmäßig die Produktmetriken im Sprint Review überprüfen, ob durch die Entwicklung von neuen Funktionalitäten auch die Produkt-Ziele erreicht werden,
- sicherstellen, dass sie die richtige Menge an Zeit mit den verschiedenen Stakeholdern und Entwicklern verbringen, indem sie bei der Sprint-Retrospektive und dem Daily Scrum aktiv teilnehmen und
- Scrum Master haben, die die Teams und die Organisation in der Umsetzung von Scrum coachen und aktiv unterstützen.
Scrum zu skalieren ist komplex, das Hinzufügen weiterer Product Owner erhöht die Komplexität und verlangsamt damit Entscheidungsfindungsprozesse. Product Owner profitieren davon, wenn sie sich an das Highlander-Prinzip zu halten.
Skalierung – ein Experiment, um den Wert zu steigern
Der einzige triftige Grund für eine Skalierung ist, dass das Produkt so erfolgreich ist, dass es unmöglich ist, die Entwicklung mit einem Team mit ausreichender Geschwindigkeit fortzusetzen, um die Kunden- und Marktanforderungen zu erfüllen.
Allerdings gibt es keine Garantie, dass mehr Teams auch zu mehr Geschwindigkeit führen. Scrum zu skalieren ist mehr als eine einfache Rechenaufgabe. Es braucht auch gesunden Menschenverstand. Die reine Mathematik sagt uns, dass wir beim Skalieren die Kosten und den Overhead mit dem Nutzen und den Vorteilen abwägen müssen. Der Common Sense sagt uns, dass wenn mehrere Teams gemeinsam ein Produkt entwickeln, es zu Abhängigkeiten zwischen den Product-Backlog-Einträgen, zwischen den Teams und bei der Integration der Entwicklungsarbeit kommen wird. Abhängigkeiten führen unausweichlich zu Verzögerungen und verlangsamen somit die Entwicklung.
Da es keine Garantie gibt, sollten Product Owner Skalierung als ein Experiment sehen. Die Hypothese, die es zu bestätigen gilt, lautet: Das Hinzufügen von Teams führt zu einer Steigerung des Produktwerts.
In der Wissenschaft hat sich beim Experimentieren das Sparsamkeitsprinzip bewährt. Es besagt, dass als Erklärung eine einfachere Theorie immer vorzuziehen ist. Je einfacher eine Theorie ist, das heißt, umso weniger Variabilität die Hypothese enthält, desto schneller und einfacher kann sie bestätigt oder widerlegt werden.
Einfachheit in der Skalierung von Scrum bedeutet, das Scrum-Rahmenwerk nur minimal zu erweitern, sodass mehrere Teams zusammenarbeiten können.
Unser gesunder Menschenverstand sagt uns, dass wir Möglichkeiten finden müssen, die entstehenden Abhängigkeiten transparent zu machen, um sie zu minimieren und so Integrationsproblemen vorzubeugen. Hierfür gibt es kein Patentrezept, aber einige Elemente haben sich immer als hilfreich erwiesen.
- Teamübergreifendes Refinement: Um Abhängigkeiten wirklich eliminieren zu können, müssen sie frühzeitig transparent gemacht werden.
- Teamübergreifendes Sprint Planning: Um die Arbeit bestmöglich auf die Teams aufzuteilen, müssen die Teams gemeinsam planen, wie sie das Sprint-Ziel erreichen wollen. Ihren teamübergreifenden Plan halten sie dann in einem teamübergreifenden Sprint Backlog fest.
- Sprint Backlog: Hier werden die teamübergreifenden Abhängigkeiten im Sprint visualisiert.
- Teamübergreifendes Daily Scrum: Bevor die Teams ihre eigene Arbeit für den Tag planen, treffen sie sich mit den anderen Teams, um mögliche Integrationsprobleme aufzudecken, welche ihre Arbeit behindern könnten.
- Teamübergreifende Sprint-Retrospektive: Am Ende des Sprints sollten alle Teams gemeinsam Verbesserungen für den nächsten Sprint identifizieren: Wenn mehrere Teams an einem Produkt arbeiten, hat die Optimierung des Ganzen immer Vorrang vor der Optimierung seiner Teile.
- Integrations-Team: Ein Team aus erfahrenen Entwicklern der einzelnen Teams, welche die Verantwortung dafür übernehmen, dass am Ende des Sprints immer eine auslieferungsfähige Version des Produkts zur Verfügung steht.
Diese Elemente, welche sich bei der Skalierung von Scrum als hilfreich erwiesen haben, da sie das Problem der Abhängigkeiten zwischen den Teams minimieren, bilden im Wesentlichen ein Rahmenwerk zur Skalierung von Scrum. Es wird als Nexus – Verbindung zwischen Mengen und Dingen – bezeichnet.
Scrum zu skalieren ist ein Experiment. Um dessen ROI zu maximieren, sind Product Owner gut beraten, nur einen minimalen Einsatz zu tätigen, bevor sie All-in gehen.
Für Anna könnte ein erstes Experiment sein
- nur ein weiteres Scrum-Team hinzuzufügen,
- frühzeitig die Arbeit zu verfeinern, damit schon im Vorfeld bekannt ist, welches Team an welchen Einträgen im Product Backlog arbeitet,
- Sprint-Planung, -Review und -Retrospektive weiterhin mit allen Beteiligten durchzuführen, unabhängig davon, zu welchen Team sie gehören und
- zu messen, ob sie durch Hinzufügen eines weiteren Teams ihre Wettbewerbsposition weiter ausbauen.
Deskaliere das Produkt, um die Komplexität zu reduzieren
Folgende Punkte sind Indikatoren dafür, dass die Skalierung von Scrum nicht den gewünschten Erfolg erzielt und es einer Handlung bedarf:
- Die teamübergreifende Abstimmung gestaltet sich als schwierig.
- Die Teams schaffen es nicht, auf ein Ziel hinzuarbeiten.
- Die Zusammenarbeit mit dem Kunden bleibt hinter den Erwartungen zurück.
- Es ist unmöglich, die Arbeit über mehrere Sprints und mehrere Teams hinweg zu planen, um der Ordnung im Backlog zu folgen.
- Keine Plattformlösung entsteht, sondern eine Reihe unabhängiger Einzellösungen.
Es kann entweder die Anzahl der Teams wieder reduziert werden oder das Produkt in Produktvarianten oder eine Plattform zerlegt werden. Zwei gängige Ansätze zur Produktteilung sind:
- Zerlege das Produkt entlang von Stakeholder-Gruppen, denen es dient. Die Auskopplung des Facebook Messengers aus der Facebook App ist ein anschauliches Beispiel hierfür.
- Zerteile das Produkt entlang funktionaler Services, um Produktvarianten zu erstellen. Am Beispiel einer Zeitung könnten das eine Web-, Mobil- und Printvariante sein.
Nach der Identifizierung potenzieller neuer Produkte können wir uns bei der Zerteilung das Gesetz von Conway zu Hilfe nehmen: Bei jeder (bestimmten) Teamorganisation gibt es eine Klasse von Designalternativen, die von einer solchen Organisation nicht effektiv verfolgt werden kann, weil die notwendigen Kommunikationswege nicht existieren. Im Umkehrschluss bedeutet das, wenn wir Kommunikationswege durch Teamstrukturen vorgeben, muss die Produktstruktur zwangsläufig folgen.
Wenn Anna diesen Hebel nutzen will, könnte sie
- ihr Produkt in eine "Alles für die Babyparty"-Variante und eine "Alles für den Kindergeburtstag"-Variante aufteilen,
- in die Entwicklung mit jeweils zwei Teams investieren und
- nur einen erfahrenen Product Owner einstellen und ihm die Verantwortung für eines der beiden Produkte übertragen.
Dadurch können langfristig die Weichen gestellt werden, zwei Produkte zu entwickeln, welche unabhängig voneinander versuchen, ihre Produkt-Ziele zu erreichen und die Unternehmensstrategie umzusetzen. Die Abstimmung kann so auf ein Mindestmaß reduziert werden und beschränkt sich dabei rein auf die strategische Ebene und weniger auf die taktische Umsetzung. Somit können Abstimmungsprobleme effektiv minimiert werden.
Wolfram Ott
am 19.04.2022