"Skalierte Agilität im Mittelstand: Warum SAFe oft die falsche erste Frage ist"

Ein mittelständischer Softwareanbieter hat aus einem Scrum-Team über zwei Jahre vier gemacht. Jedes Team liefert zuverlässig, jeder Sprint-Review sieht gut aus – und trotzdem kommt das Gesamtprodukt kaum voran. Team A wartet auf eine Schnittstelle von Team C, Team B baut ein Feature, das Team D gerade erst verworfen hat, und im Status-Meeting wird immer wieder dieselbe Abhängigkeit neu entdeckt. Die naheliegende Reaktion: "Wir brauchen ein Skalierungsframework." Die meistgenannte Antwort im Netz: SAFe. Genau hier beginnt für viele Mittelständler der eigentliche Fehler – nicht bei der Frage, ob man skalieren soll, sondern bei der Frage, wie viel Rahmenwerk man dafür wirklich braucht.

Das Missverständnis: Skalierung ist keine Frage der Größe allein

Skalierte Agilität existiert, weil ein einzelnes Scrum-Team an Grenzen stößt, sobald mehrere Teams an einem gemeinsamen Produkt arbeiten und ihre Arbeit synchronisiert werden muss. Das Problem ist real. Die verbreitete Annahme ist jedoch, dass mehr Teams automatisch mehr Prozess brauchen – und dass das bekannteste Framework automatisch das richtige ist. Das Scaled Agile Framework (SAFe) ist mit seinen mehreren Ebenen, definierten Rollen und Program-Increment-Zyklen ursprünglich für sehr große Organisationen mit dutzenden bis hunderten Teams entwickelt worden. Ein Mittelständler mit vier bis acht Teams, der SAFe eins zu eins übernimmt, importiert damit einen Koordinationsapparat, der für eine andere Größenordnung gebaut wurde. Das Ergebnis sind oft zusätzliche Rollen, Meetings und Artefakte, ohne dass die eigentliche Ursache der Abstimmungsprobleme adressiert wird.

Die gängigen Frameworks im Kurzüberblick

Für die Praxis lohnt sich ein nüchterner Blick auf die vier am häufigsten diskutierten Ansätze, jenseits von Marketing und Zertifizierungsgeschäft:

SAFe bietet die umfassendste Struktur: klare Ebenen von Team über Programm bis Portfolio, definierte Rollen wie Release Train Engineer, und synchronisierte Planungszyklen (Program Increments). Der Vorteil ist eine hohe Verzahnung mit Unternehmenszielen und Budgetprozessen. Der Preis ist ein spürbarer Einführungs- und Schulungsaufwand, der sich erst ab einer größeren Zahl von Teams wirklich amortisiert.

LeSS (Large-Scale Scrum) geht den entgegengesetzten Weg: so nah wie möglich am ursprünglichen Scrum bleiben. Ein Product Owner, ein gemeinsames Backlog, gemeinsame Reviews und Retrospektiven für mehrere Teams. LeSS fügt bewusst wenig hinzu – dafür verlangt es ein bereits reifes agiles Verständnis in den Teams, weil vieles über Selbstorganisation statt über zusätzliche Rollen gelöst wird.

Nexus, entwickelt von den Autoren des Scrum Guide, ist für bis zu neun Teams gedacht und ergänzt Scrum um ein schlankes Integrationsteam, das dafür sorgt, dass die Arbeit mehrerer Teams zu einem funktionierenden Produktinkrement zusammenläuft. Nexus gilt als vergleichsweise leicht erlernbar und eignet sich oft als Einstieg, wenn Integration – nicht strategische Portfoliosteuerung – das drängendste Problem ist.

Scrum@Scale setzt auf Modularität: Teams werden über "Scrum of Scrums"-Strukturen verzahnt, wobei Organisationen selbst entscheiden, welche Bausteine sie in welcher Reihenfolge einführen. Das macht den Ansatz flexibel, verlangt aber ebenfalls Erfahrung, um die Bausteine sinnvoll zusammenzusetzen.

Faustregeln für die Auswahl

Statt der Frage "Welches Framework ist am bekanntesten?" helfen im Mittelstand andere Kriterien. Erstens die Teamanzahl: Bei zwei bis vier Teams ist ein schlanker Ansatz wie Nexus oder ein leicht angepasstes LeSS fast immer ausreichend, SAFe wird selten vor der zweistelligen Teamzahl wirtschaftlich. Zweitens die Reife der Teams: Je weniger etabliert Scrum in den einzelnen Teams bereits ist, desto mehr externe Struktur (eher SAFe-nah) hilft – reife, selbstorganisierte Teams profitieren dagegen stärker von schlanken Ansätzen wie LeSS. Drittens die eigentliche Engpassfrage: Geht es primär um technische Integration mehrerer Teams zu einem Produkt, ist Nexus meist die zielgenauere Antwort als ein komplettes Portfolio-Framework. Geht es dagegen um die Verzahnung mit Budget- und Portfolioentscheidungen auf Unternehmensebene, wird ein Teil des SAFe-Gedankens relevant, auch ohne das volle Framework zu übernehmen. Und viertens: Jedes Framework lässt sich anpassen. Die Empfehlung erfahrener Coaches, mit dem einfachsten Ansatz zu starten, der tatsächlich zur Organisation passt, und ihn erst bei konkretem Bedarf zu erweitern, hat sich in der Praxis deutlich häufiger bewährt als der umgekehrte Weg – mit einem umfassenden Framework zu starten und es später wieder zu verschlanken.

Ein typisches Beispiel

Ein Maschinenbauzulieferer mit vier Entwicklungsteams für eine gemeinsame IoT-Plattform stand genau vor der eingangs beschriebenen Situation. Statt direkt in eine SAFe-Einführung mit Release Train Engineer und Program-Increment-Planung zu investieren, entschied sich das Unternehmen für Nexus: ein kleines Integrationsteam aus je einem Vertreter pro Team plus dem Product Owner, ein gemeinsames Sprint-Review und ein "Nexus Daily" zur Klärung von Abhängigkeiten. Der Effekt zeigte sich nicht sofort, aber innerhalb weniger Sprints: Abhängigkeiten wurden im Integrationsteam sichtbar, bevor sie zum Blocker wurden, und der administrative Mehraufwand blieb überschaubar. Erst zwei Jahre später, als ein fünftes und sechstes Team hinzukamen und die Portfoliosteuerung über mehrere Produktlinien hinweg relevant wurde, übernahm das Unternehmen gezielt einzelne SAFe-Elemente – nicht das gesamte Framework.

Auf den Punkt

Skalierte Agilität löst ein echtes Koordinationsproblem, ist aber kein Wettbewerb um das umfangreichste Framework. Für die meisten mittelständischen Organisationen mit einer überschaubaren Zahl von Teams sind schlanke Ansätze wie Nexus oder LeSS der realistischere Startpunkt als SAFe. Entscheidend ist, zunächst den eigentlichen Engpass zu identifizieren – Integration, Selbstorganisation oder Portfoliosteuerung – und erst danach das dazu passende Maß an Struktur zu wählen, mit der klaren Bereitschaft, es später gezielt zu erweitern statt es vorab zu maximieren.