Alle Artikel

Was Hänschen nicht lernt - Scaling Scrum

Nach den ersten guten Erfahrungen mit Scrum, versuchen Organisationen oft, die Prozesse eine oder mehrere Ebenen höher zu heben. Kann das gut gehen? Spoiler Alert: Ich denke, eher nicht.

Scaling Scrum

Was macht denn Scrum eigentlich aus

Bevor wir über das Skalieren von Scrum reden, sollten wir klären, was Scrum eigentlich ist. Wenn man sich den Scrum Guide genauer ansieht, stellt man recht schnell fest, dass so Themen wie Change Management, Risk Management, Communication Management - kurz: alles, was über die Grenzen des Teams hinausgeht - nicht behandelt werden. Das ist ja auch gar nicht der Anspruch. Scrum ist eine Sammlung von Prozessen und Regeln, mit deren Hilfe ich das tägliche (Software-)Projektgeschäft auf Teamebene organisieren und abwickeln kann. Nicht mehr und nicht weniger.

Ein kurzer Ausflug: Scrum war ursprünglich - noch vor Schwaber und Sutherland - wesentlich weiter gedacht. Takeuchi und Nonaka verstanden darunter einen holistischen Ansatz zur Produktentwicklung. Dazu kommen wir aber gleich nochmal.

Grenzen und der Versuch deren Überwindung

Diese Fokussierung auf die Softwareentwicklung und dort auf das Tagesgeschäft ist der Grund, warum Organisationen häufig mit der Einführung von Scaled Scrum als Lösung für alles scheitern. Weil ich dann versuche, meine ganze Arbeit mit etwas abzubilden, das dafür gar nicht gedacht ist.
Einige dieser Organisationen haben sich nach den ersten Erfahrungen nach anderen Methodiken umgesehen. Manche wählen einen Hybridansatz. Andere haben den Versuch unternommen, Scrum so zu erweitern, dass ich damit sämtliche Ebenen und Aspekte meines Project-Lifecycle abdecke.

Dann also auf zum Skalieren

Im Grunde gibt es zwei Ansätze, Scrum zu skalieren. Einmal kann ich meine Teams gleichschalten und in Zyklen arbeiten. Oder aber ich arbeite und denke in sogenannten Etappen und habe die Teams eher lose gekoppelt. Lasst uns mal einen Blick auf die bekanntesten Protagonisten werfen:

Large Scale Scrum

Large Scale Scrum - auch LeSS genannt - versucht, Scrum mehr oder weniger unverändert über mehrere - maximal acht - Teams drüber zu stülpen. Sprich, ich habe die bekannten Events. Nur nicht mit einem Team, sondern mit mehreren gleichzeitig und gemeinsam. Dort, wo es unübersichtlich wird (Daily, Retro, etc.), halte ich meine Events doppelt ab. Einmal zusammen (bzw. mit Vertretern aller Teams) und einmal in den einzelnen Teams.

Scaled Agile Framework

Das Scaled Agile Framework (SAFe) fasst mehrere Sprints zu Etappen zusammen. Planung und Rückblick dieser Program Increments läuft teamübergreifend ab. Während einer Etappe sind die Teams aber - bis auf übergreifende Termine, wie Scrum of Scrum und gemeinsame Sprint Reviews - weitgehend autonom.

Inflating Scrum

Theoretisch

Grundsätzlich und auf den ersten Blick sind das beides keine so schlechte Ideen. In den allerersten Inkarnationen war Scrum, wie gesagt, weder auf Softwareentwicklung, noch auf die Teamebene beschränkt. Vielmehr ging es darum, mittels interdisziplinären Teams eine kontinuierliche Weiterentwicklung meiner Produkte zu schaffen. Das Denken in Increments und Spiralen war auch bereits tief im System verwurzelt. Aber das was wir heute unter Scrum verstehen, ist doch was ganz anderes.

In der Physik - sorry für den abrupten Themenwechsel - steht man vor dem Problem, dass sich die Abläufe auf der kleinsten Ebene und die auf der größten Ebene nicht wirklich mit nur einer gesamten Theorie beschreiben lassen. Selbst das Standardmodell der Elementarteilchenphysik ist nur eine unzulängliche Zusammenfassung. Und ähnlich geht es uns oft im Projektmanagement. Methodiken, die die großen Zusammenhänge erklären, lassen die feingranularen Abläufe außen vor. Und umgekehrt gilt das Gleiche. Und das ist in meinen Augen auch der Grund, warum sich Scrum so schlecht skalieren lässt. Das wäre, wie wenn ich versuchen würde, die Ausdehnungsgeschwindigkeit des Universums anhand der Beinlänge von Wimperntierchen zu berechnen. Schlechter Vergleich, ich weiß. Aber Ihr wisst, worum es mir geht.

Schwaber und Sutherland haben die Idee von Scrum komplett auf die Teamebene und das Tagesgeschäft innerhalb des Change-Prozesses heruntergezogen. Darum funktioniert es dort auch so gut. Weil der Einsatzort sehr begrenzt ist. Sobald ich aber auf eine höhere oder auch nur eine benachbarte Ebene komme, wird der Scrum Guide mit seinen 16 Seiten Inhalt schnell recht dünn.

Wenn ich einen Hammer in der Hand halte…

Was bedeutet das also? Dass zu wenig Futter dran ist. Was sich bei allen Versuchen einer Skalierung findet, ist ein ganzer Haufen neuer Rollen und Prozesse und Namen. Da werden dann Begriffe erfunden und Konzepte aus der Luft gegriffen. Klingt das Ganze dann richtig toll und trendy? Definitiv! Funktioniert es? Meh. Wie denn auch? Scaling Scrum ist viel zu oft eigentlich eher Inflating Scrum.

Meiner Erfahrung nach, machen Organisationen - und dort oft die Treiber der Agilisierung - hier einen großen Denkfehler. Und das soll nicht heißen, dass diese Personen generell was falsch machen. Ganz im Gegenteil. Und das soll bitte auch nicht heißen, dass ich glaube, schlauer zu sein, als all diese Agile Coaches zusammen. Ganz im Gegenteil! Ich habe nur oft beobachtet, dass, wenn es um eine Skalierung von Scrum geht, oft zwei Dinge miteinander verwechselt werden: Agilität als Ansatz, Denkweise, Menschenbild, Mindset. Und Scrum als Projektmanagementframework. Scrum hat nun mal klare Grenzen. Und meiner Meinung nach, sollte man sich nicht Gedanken über eine Skalierung, sondern eher über eine Einbettung von Scrum in die Projektmanagement- und Prozessmethodik einer Organisation machen. Als ein Ansatz und Werkzeug von vielen.

Und Scrum ist sicher auch nicht der Hebel, mit dem ich meine Organisation “agilisieren” kann. Eigentlich sollte es vollkommen egal sein, ob ich agil bin, oder nicht.
Wenn ich das beherzige und Scrum das bleiben lasse, als was es gedacht ist, habe ich ein wahnsinnig wirkungsvolles und produktives Framework für den Bereich rechts oben auf meiner Stacey-Matrix. Und das ist eigentlich genau das, was ich benötige und will.

Bilder von Tyler Milligan und Toni Cuenca auf Unsplash.

Gedanken über modernes Projektmanagement - klassisch, agil, hybrid. Stephan Weinhold ist auch auf LinkedIn und XING. Du solltest ihm außerdem auf Twitter folgen.