Skalierung von Scrum: Diese 7 Fragen müssen Scrum Master beantworten – sonst scheitert die Koordination mehrerer Teams

Leider erinnere ich mich noch allzu gut daran:

Vor einigen Jahren betrat ich den Teamraum eines meiner drei Scrum Teams und sah einem Entwickler über die Schulter. Das UI, welches er entwickelte, erinnerte mich an die Arbeit meines anderen Teams. Deshalb fragte ich: „Reviewst du den Code des anderen Teams?“ Er entgegnete: „Nein, das ist das neue Feature für unseren Sprint. Damit habe ich gerade angefangen.“ Dann dämmerte es mir.

„Kann es sein, dass beide Teams am gleichen Feature arbeiten?“

Das ist nur eines von vielen Problemen, die bei der Skalierung von Scrum auftreten.

Und unter uns: Einem festen Skalierungsprozess zu folgen, wird dich wahrscheinlich vor vielen dieser Probleme nicht bewahren. Im Gegenteil. Starre Prozesse überdecken häufig die wirklichen Koordinationsprobleme, die in den Teams bei der Zusammenarbeit entstehen. Deshalb hat es sich für mich bewährt, mich bei der Skalierung von Scrum weniger auf einen Prozess zu verlassen, sondern mir die richtigen Fragen zu stellen.

Und diese Fragen möchte ich dir heute vorstellen:

Frage #1: Wie können Meetings mit mehreren Teams, die gemeinsam an einem Produkt arbeiten, effektiv durchgeführt werden?

Dass Meetings mit großen Gruppen nicht gut funktionieren, ist simple Mathematik.

Hierfür brauchen wir nur die Anzahl der Kommunikationspfade zu betrachten. Für bestmögliches gemeinsames Verständnis müsste jeder im Team mit jedem in der Gruppe sprechen. Nur so kann jede Person sichergehen, dass ihr Gesprächspartner das gleiche Verständnis hat. Betrachten wir nun eine Gruppe mit 5 Personen und bilden alle möglichen Paare innerhalb des Teams, dann kommen wir auf 10 Möglichkeiten. Das heißt: Es müssen zehn Gespräche stattfinden, damit wir gemeinsames Verständnis herstellen können. Wächst die Gruppe, erhöht sich auch die Anzahl der Kommunikationspfade. Bei Gruppen mit 10 Personen sind es 45 Pfade und bei Gruppen mit 50 bereits 1125 Pfade. Du siehst das Problem, oder?

Skalierung geht immer zulasten des gemeinsamen Verständnisses.

Deshalb stelle ich mir bei der Skalierung immer die Frage:

Welche Wege gibt es, um Meetings mit großen Gruppen oder mehreren Teams so zu gestalten, dass sie produktiv sind und gemeinsames Verständnis fördern?

Frage #2: Wie lässt sich psychologische Sicherheit über die Grenzen eines Teams hinweg aufbauen?

Wie lautet der Schlüsselfaktor für effektive Teamarbeit?

Nach Amy Edmondson, der Professorin an der Harvard Business School, ist es psychologische Sicherheit. Wenn wir uns im Team frei äußern können, ohne Angst vor negativen Konsequenzen, dann fördert das Offenheit, Lernen und Innovation im Team.

Bei der Skalierung von Scrum stellt sich dann unmittelbar die Frage:

Skaliert psychologische Sicherheit?

Aus meiner Erfahrung mit vielen und großen Teams würde ich das klar verneinen. Es ist einfach schwieriger bis unmöglich, mit vielen Menschen gemeinsam auf positive Erfahrungen zurückzublicken. Und je größer die Gruppe von Menschen, desto schwieriger wird es für das einzelne Mitglied, einzuschätzen, ob es wirklich sicher ist, etwas Kritisches auszusprechen. Professorin Edmondson betont dies auch. In ihrer Arbeit schreibt sie, dass in großen Gruppen mit vielen Beziehungspfaden und komplexen Abhängigkeiten die häufige, persönliche Interaktion leidet. ​Eine rigorose wissenschaftliche Theorie, wie gut psychologische Sicherheit skaliert, konnte ich aber noch nicht finden.

Deshalb müssen wir hier unsere eigenen Erfahrungen machen und nach Wegen suchen, wie wir die Vorteile von psychologischer Sicherheit in kleinen Teams auch auf mehrere Teams übertragen können.

Die Frage, die ich mir deshalb immer stelle:

Was kann ich dafür tun, psychologische Sicherheit auch über die Grenzen eines Teams auszubauen?

Frage #3: Wie lässt sich ein einheitliches Verständnis der Prioritäten für alle beteiligten Teams schaffen?

Was empfiehlt der Scrum Guide, um einheitliches Verständnis über Prioritäten herzustellen?

Eine Person im Team übernimmt die Verantwortung dafür,

• dass es ein Ziel gibt, das mit dem Produkt erreicht werden soll,
• dass jeder im Team das Ziel verstanden hat,
• dass die Mitglieder im Team und die Stakeholder zusammen erarbeiten, welche Verbesserungen am Produkt unternommen werden könnten, um dieses Ziel zu erreichen.

Noch mal zusammengefasst: Es gibt einen Product-Owner, ein Produktziel und ein Product-Backlog. Dies fordert ein einheitliches Verständnis, was wichtig ist.

Wenn jetzt mehrere Teams zusammenarbeiten sollen, stellen sich unausweichlich diese Fragen:

• Wie viele Produkte gibt es?
• Wie viele Product-Owner gibt es?
• Wie viele Ziele gibt es?
• Wie viele Product-Backlogs gibt es?

Der Scrum Guide empfiehlt uns weiterhin, dass die Antwort auf alle Fragen „eins“ lautet. Dies fördert einheitliches Verständnis und schnelle Entscheidungen.

Allerdings folgt Skalierung niemals einem Bauplan. Und deshalb stelle ich mir die Frage:

Wie (noch) lässt sich ein einheitliches Verständnis der Prioritäten für alle beteiligten Teams schaffen?

Frage #4: Wie pflegen Teams teamübergreifende technische Standards und den Wissensaustausch?

Skalierung = schnelles Chaos.

Die Koordination von Teams, Menschen und Arbeit wächst Unternehmen schnell über den Kopf. (Glaub mir, wenn ich das sage. Ich habe es bereits einige Male miterlebt.) Viele Unternehmen reagieren auf diese Komplexität mit Standards und Regeln, an die sich jedes Team halten muss. Beispiele kennst du zur Genüge: Denke nur an die jährliche Frist zur Budgetvergabe.

Regeln und Standards haben auch ihre Kehrseite.

Da sie starr sind, lassen sie wenig Spielraum für Interpretation und fordern deshalb nur selten die Übernahme von Verantwortung. Allerdings geht es genau darum in Scrum. Scrum Teams managen ihre Arbeit selbst. Sie übernehmen Verantwortung, indem sie entscheiden, wer, was, wie und wann entwickelt.

Die Frage, die sich daraus ergibt:

Wie können wir die Koordination von Teams, Menschen und Arbeit weniger chaotisch gestalten – und das, ohne die Übernahme von Verantwortung einzuschränken?

Agilität lebt von schnellen Entscheidungen und Skalierung sollte diese nicht gefährden.

Deshalb stelle ich mir die Fragen:

• Welche Standards müssen wirklich als feste Regeln in der Definition-of-Done festgehalten werden?
• Wie können technische Standards über Teamgrenzen hinweg eingehalten werden?
• Wie lässt sich Wissensaustausch zwischen Teams ohne Regeln fördern?

Frage #5: Von Kompetenz- zu interdisziplinären Teams: Wie gelingt die Umstrukturierung?

Fähigkeiten und Kompetenzen in Abteilungen und Teams zu bündeln, macht durchaus Sinn.

Ist das Ziel, effizient zu arbeiten, und gleicht die Arbeit immer gleichen Handgriffen, dann ist dies wahrscheinlich sogar das Patentrezept. Die Frage, die sich nun stellt:

Entspricht Softwareentwicklung dieser Charakterisierung?

Ich denke eher weniger.

Softwareentwicklung hat nur wenig von Fließbandfertigung in einem Automobilkonzern. Du erkennst das daran, wie schwer sich Entwickler tun, vorherzusagen, wie lange ein Handgriff dauern wird und wann sie fertig sein werden. Da ungenaue Vorhersagen und geplatzte Liefertermine ein Risiko mit zusätzlichen Kosten für Unternehmen darstellen, versuchen Scrum Teams, dieses Risiko mit interdisziplinären Teams zu reduzieren. Die Rechnung ist ganz einfach: Haben wir alle Fähigkeiten im Team, gibt es weniger unkontrollierbare Abhängigkeiten und somit weniger Wartezeiten. Arbeitet das ganze Team an einer Sache, haben alle im Team den gleichen Wissensstand und wir sparen uns übermäßige Dokumentation und Zeit, uns wieder in die Arbeit hineinzudenken.

Deshalb bedeutet Scrum für die meisten Unternehmen eine Umstrukturierung der Teamstruktur. Und was für ein Team schon schwierig ist, wird für mehrere Teams gleichzeitig schnell zum Albtraum.

Die Frage ist also nicht, ob mehrere Teams interdisziplinär zusammenarbeiten sollten, sondern wie wir dort hinkommen.

Und auf diesem Weg gibt es unterschiedliche Teamtypen, die uns dabei helfen können. Ich denke hier an „Enabling Team“, „Complicated Subsystem Team“ oder auch „Platform Team“.

Frage #6: Wie werden Führungskräfte aus dem mittleren Management in agile Transformation eingebunden?

Scrum kennt keine Manager.

Das ist erst mal gut. Denn sonst gäbe es keinen Anlass, die Selbstmanagement-Fähigkeiten des Teams zu stärken. Nur ist die Wahrheit: Nur weil Scrum die Verantwortung des Managements gleich auf die Schultern von Product-Owner, Entwicklern und Scrum Master verteilt, bedeutet das nicht, dass keine Manager im Unternehmen eingestellt sind.

Darüber hinaus sollten wir auch nicht vergessen:

Der Scrum Guide empfiehlt, wie die Arbeit gemanagt werden soll. Nicht weniger, aber auch nicht mehr. Wie Mitarbeitende eingestellt, entwickelt und geführt werden, darüber steht nichts im Guide.

Deshalb stellt sich bei der Skalierung auch immer die Frage: Was ist der Platz für disziplinarische Führungskräfte und Manager?

Oder konkreter frage ich mich:

• Ist ihr Platz im Team als Mitglied des Teams?
• Bilden sie ein separates Team?
• Oder bleiben sie bei der Skalierung außen vor?

Aus meiner Sicht stellt das mittlere Management einen wichtigen Hebel in jeder agilen Transformation dar. Es bildet das Bindeglied zwischen Scrum Teams und der restlichen Organisation.

Und deshalb lautet die alles entscheidende Frage:

Wie lässt sich dieser Hebel nutzen?

Frage #7: Wie lässt sich das Management davon überzeugen, dass mehr Teams nicht zwangsläufig mehr Wert bedeuten?

Softwareentwicklung stellt viele Management-Philosophien auf den Kopf.

Eine davon: „Viel hilft viel!“

Erstmalig wurde diese Antithese wahrscheinlich von Fred Brooks formuliert: „Adding manpower to a late software project makes it later.“

Warum ist das so?

• Der Koordinationsaufwand steigt: Die Verteilung der Aufgaben erfordert mehr Abstimmungsschleifen und Synchronisation. Zusätzliche Teamleiter oder Koordinatoren tragen nicht direkt zur Wertschöpfung bei und können diesen Aufwand auch nicht zwingend verringern. Insgesamt wächst dieser Aufwand nicht linear.
• Neben technischen Koordinationsaspekten spielen soziale Dynamiken eine Rolle: Die individuelle Verantwortlichkeit sinkt mit der Gruppengröße. Dies ist als Ringelmann-Effekt bekannt: Je größer die Gruppe, desto geringer wird tendenziell der Beitrag des Einzelnen, da Verantwortung diffundiert.
• Die Teamkohäsion sinkt: Das „Wir“-Gefühl im Team sinkt, je größer das Team ist. Die Erklärung ist die gleiche wie die, warum sich die psychologische Sicherheit mit der Teamgröße verringert.
• Entscheidungsfindung wird langsamer: Natürlich lässt sich das Phänomen „Viele Köche verderben den Brei“ mit Abstimmungen, Gremien oder mehreren Hierarchieebenen abmildern. Unstrittig ist aber, dass diese Entscheidungen in Gruppen mehr Zeit kosten.
• Kontextwechsel steigen: Je mehr Personen im Team oder je mehr Teams zusammenarbeiten, desto mehr unterschiedliche Aufgaben gibt es. Dies führt wahrscheinlich zu vermehrten Kontextwechseln der Entwickler zwischen den Aufgaben oder Projekten.

All diese Faktoren erklären aus meiner Sicht, warum größere Teams nicht proportional mehr Wert liefern.

Die Frage, die sich damit stellt:

Wie lässt sich auch das Management davon überzeugen?

Hast du Fragen zur Skalierung von Scrum oder würdest gerne einen Workshop dazu in deinem Unternehmen durchführen?

Dann schreibe mich gerne an.

Ich war einige Jahre für die Weiterentwicklung des „Scaled Professional Scrum“-Trainings der Scrum.org mitverantwortlich und bin zuversichtlich, dass ich dir weiterhelfen kann.