Scaling Agile: SAFe®, LeSS®, Nexus® & Scrum@Scale im Vergleich

Ein Scrum-Team funktioniert hervorragend. Dann werden daraus drei Teams, sechs Teams, zehn Teams – und plötzlich entstehen Fragen, die ein einzelnes Team nie beantworten musste: Wer priorisiert teamübergreifend? Wie koordinieren sich Teams, die an demselben Produkt arbeiten? Wer entscheidet über Abhängigkeiten zwischen ihnen? Genau hier beginnt Scaling Agile.

Dieser Beitrag beschreibt bewusst nicht jedes Detail von SAFe®, LeSS®, Nexus® und Scrum@Scale – das würde den eigentlichen Zweck dieses Artikels verfehlen. Die entscheidende Frage lautet nicht "Was ist SAFe?", sondern: Welches Framework passt wann? Wer sich zunächst mit den Grundlagen von Scrum selbst vertraut machen möchte, findet sie in unserem Beitrag Was ist Scrum? Der umfassende Leitfaden für Unternehmen.

Zwei Gedanken ziehen sich durch den gesamten Beitrag: Scaling Agile bedeutet nicht, Scrum größer zu machen, sondern die Zusammenarbeit zwischen mehreren Teams wirksam zu organisieren. Und: Das beste Skalierungsframework ist oft das einfachste, das tatsächlich zur Organisation passt – nicht das umfangreichste.

Abb.: Scaling Evolution – vom einzelnen Team bis zur gesamten Organisation

Was bedeutet Scaling Agile?

Scaling Agile ist keine größere Version von Scrum. Ein einzelnes Scrum-Team braucht kein zusätzliches Framework, um agil zu arbeiten – Scrum selbst reicht dafür vollständig aus. Scaling Agile setzt erst dort an, wo mehrere Teams gemeinsam an einem Produkt oder in derselben Organisation arbeiten und dabei Abstimmung brauchen, die ein einzelnes Team allein nicht leisten kann: gemeinsame Priorisierung, koordinierte Releases, transparente Abhängigkeiten. Es geht also nicht darum, Scrum aufzublähen, sondern darum, die Zusammenarbeit zwischen Teams zu organisieren, die jede für sich bereits nach Scrum arbeiten.

Wann reicht Scrum allein nicht mehr?

Einige Signale deuten darauf hin, dass ein einzelnes Team an seine koordinativen Grenzen stößt: mehrere Teams arbeiten am selben Produkt, gemeinsame Releases müssen abgestimmt werden, Abhängigkeiten zwischen Teams häufen sich, oder die Organisation zählt bereits hunderte Entwicklerinnen und Entwickler, die in unterschiedlichen Teams organisiert sind. In solchen Situationen kann ein Skalierungsframework echten Mehrwert schaffen, weil es Strukturen für genau diese teamübergreifenden Fragen liefert.

Team A → Team B → Release → Kunde

Diese einfache Kette zeigt, woher der Koordinationsbedarf überhaupt kommt: Sobald das Ergebnis für den Kunden von der Arbeit mehrerer Teams abhängt, reicht es nicht mehr, dass jedes Team für sich gut funktioniert – die Abhängigkeit zwischen Team A und Team B muss aktiv organisiert werden, sonst verzögert sich das gemeinsame Release an genau dieser Schnittstelle.

Wann sollte NICHT skaliert werden?

Ebenso wichtig ist die Gegenfrage. Wenn eine Organisation lediglich zwei Teams hat, ist ein umfassendes Skalierungsframework meist überdimensioniert – die nötige Abstimmung lässt sich in dieser Größenordnung oft informell lösen. Wenn die Kommunikation zwischen bestehenden Teams bereits schlecht funktioniert, wird ein zusätzliches Framework diese Kommunikation nicht reparieren, sondern lediglich mehr Struktur um ein bestehendes Problem herum bauen. Und wenn grundlegende Scrum-Erfahrung im Unternehmen noch fehlt, wird ein Skalierungsframework diese Lücke nicht schließen, sondern sie auf mehrere Teams gleichzeitig ausdehnen.

Aus unserer Erfahrung

Viele Unternehmen glauben, dass sie ein Skalierungsframework brauchen. Tatsächlich brauchen sie oft zunächst besseres Scrum. Ein Framework wie SAFe oder LeSS löst kein Team-Problem – es organisiert die Zusammenarbeit zwischen Teams, die für sich bereits funktionieren.

Überblick über die wichtigsten Frameworks

Vier Frameworks dominieren aktuell die Diskussion um Scaling Agile. SAFe® (Scaled Agile Framework) bietet die umfassendste, am stärksten strukturierte Antwort und richtet sich vor allem an große, oft historisch gewachsene Organisationen. LeSS® (Large-Scale Scrum) verfolgt den gegenteiligen Ansatz: so wenig zusätzliche Struktur wie möglich, so nah wie möglich am ursprünglichen Scrum. Nexus®, entwickelt von denselben Autoren wie der Scrum Guide, positioniert sich bewusst als leichtgewichtige Erweiterung für eine überschaubare Anzahl von Teams. Und Scrum@Scale setzt auf ein modulares Baukastenprinzip, das Organisationen flexibel an ihre eigene Struktur anpassen können.

Framework	Philosophie in einem Satz
SAFe®	Struktur – klare Ebenen und Rollen für große Organisationen
LeSS®	Weniger Regeln – so nah wie möglich am ursprünglichen Scrum
Nexus®	Minimal erweitertes Scrum für wenige, eng verzahnte Teams
Scrum@Scale	Modularität – Bausteine flexibel nach Bedarf kombinieren

Diese Philosophien erklären zugleich, warum kein Framework grundsätzlich "besser" ist als ein anderes – sie treffen einfach unterschiedliche Grundentscheidungen darüber, wie viel zusätzliche Struktur sinnvoll ist.

SAFe®

Ziel. SAFe verfolgt das Ziel, agiles Arbeiten in großen, oft stark strukturierten Organisationen mit mehreren Ebenen – Team, Programm, Portfolio – konsistent zu verankern.

Aufbau. Das Framework definiert mehrere Ebenen oberhalb des einzelnen Teams, verbunden durch gemeinsame Planungszyklen und definierte Rollen auf jeder Ebene.

Vorteile. Klare, detailliert ausgearbeitete Struktur, die auch in komplexen, stark regulierten Organisationen Orientierung bietet, sowie breite Erfahrung und Marktverbreitung.

Nachteile. Hoher struktureller Aufwand und die Gefahr, dass Teams sich stärker an vorgegebenen Prozessen orientieren als an den ursprünglichen agilen Prinzipien.

Geeignet für. Große Organisationen mit vielen Teams, oft historisch gewachsener Struktur und dem Bedarf nach unternehmensweiter Planungssynchronisation.

Typische Unternehmen. Konzerne und große Unternehmen mit komplexen Produktlandschaften, häufig in regulierten Branchen wie Finanzwesen oder Industrie.

LeSS®

Ziel. LeSS verfolgt das Ziel, Scrum-Prinzipien auf mehrere Teams auszuweiten, ohne dabei unnötige zusätzliche Struktur einzuführen.

Aufbau. Ein gemeinsames Product Backlog, ein gemeinsamer Product Owner und weitgehend unveränderte Scrum-Events, ergänzt um zusätzliche Koordinationsmechanismen zwischen den Teams.

Vorteile. Bleibt nah am ursprünglichen Scrum, vermeidet zusätzliche Rollen und Hierarchieebenen, fördert echte teamübergreifende Selbstorganisation.

Nachteile. Erfordert eine bereits reife Scrum-Kultur und hohe Disziplin, da wenig zusätzliche Struktur zur Verfügung steht, die Lücken kompensiert.

Geeignet für. Organisationen mit mehreren, bereits erfahrenen Scrum-Teams, die an einem gemeinsamen Produkt arbeiten.

Typische Unternehmen. Produktorientierte Unternehmen mit ausgeprägter agiler Kultur, häufig im Software- und Technologieumfeld.

Nexus®

Ziel. Nexus erweitert Scrum um ein Minimum an zusätzlicher Struktur, um die Integration der Arbeit mehrerer Teams an einem gemeinsamen Produkt sicherzustellen.

Aufbau. Ein zusätzliches Nexus Integration Team koordiniert die Zusammenarbeit, ergänzende Events sorgen dafür, dass Abhängigkeiten zwischen Teams sichtbar bleiben.

Vorteile. Sehr nah am Scrum Guide, überschaubarer Zusatzaufwand, entwickelt von denselben Autoren wie Scrum selbst.

Nachteile. Stößt bei einer größeren Anzahl von Teams an strukturelle Grenzen – Nexus ist bewusst für eine begrenzte Teamzahl konzipiert.

Geeignet für. Eine überschaubare Anzahl von Teams, typischerweise bis zu neun, die an einem gemeinsamen Produkt arbeiten.

Typische Unternehmen. Mittelständische Softwareunternehmen mit wenigen, eng zusammenarbeitenden Teams.

Scrum@Scale

Ziel. Scrum@Scale verfolgt das Ziel, Scrum-Prinzipien modular auf beliebig viele Teams auszuweiten, ohne ein starres Gesamtmodell vorzugeben.

Aufbau. Ein Netzwerk aus Scrum-Teams, koordiniert über ein "Scrum of Scrums" auf Team-Ebene und ein vergleichbares Koordinationsgremium auf Produktebene.

Vorteile. Hohe Flexibilität, da einzelne Module je nach Bedarf der Organisation kombiniert werden können, statt ein komplettes Rahmenwerk zu übernehmen.

Nachteile. Die Flexibilität verlangt zugleich mehr eigene Gestaltungsarbeit – es gibt weniger vorgefertigte Antworten als etwa bei SAFe.

Geeignet für. Organisationen mit bereits ausgeprägter agiler Erfahrung, die ihre Skalierung selbst gestalten möchten, statt ein festes Modell zu übernehmen.

Typische Unternehmen. Agile Unternehmen mit gewachsener Scrum-Praxis, die organisch skalieren, statt ein komplettes Rahmenwerk einzuführen.

Frameworks im direkten Vergleich

Kriterium	SAFe®	LeSS®	Nexus®	Scrum@Scale
Typische Größe	Sehr groß	Mehrere Teams	Bis ca. 9 Teams	Beliebig skalierbar
Komplexität	Hoch	Niedrig bis mittel	Niedrig	Mittel
Zusätzliche Rollen	Mehrere neue Rollen	Kaum neue Rollen	Ein Integration Team	Koordinationsgremien
Planungsansatz	Große, unternehmensweite Planungszyklen	Gemeinsames Backlog, ein Sprint	Gemeinsames Sprint Planning	Modular, je nach Bedarf
Koordination	Über definierte Ebenen und Rollen	Über gemeinsame Events	Über Integration Team	Über Scrum of Scrums
Aufwand der Einführung	Hoch	Mittel	Niedrig	Mittel
Flexibilität	Eher gering	Mittel	Mittel	Hoch
Governance-Tiefe	Sehr ausgeprägt	Gering	Gering bis mittel	Anpassbar
Release-Ansatz	Programminkremente über mehrere Sprints	Gemeinsames Produktinkrement je Sprint	Integriertes Increment je Sprint	Abhängig vom gewählten Modul
Lernkurve	Steil	Moderat	Flach	Moderat
Kulturelle Veränderung	Signifikant	Erfordert bereits reife Kultur	Moderat	Abhängig von gewählten Modulen
Geeignet für	Große, komplexe Organisationen	Reife, produktorientierte Teams	Wenige, eng verzahnte Teams	Organisch wachsende Organisationen

Wie finden Sie das passende Framework? Eine Orientierung

Die folgende Übersicht ersetzt keine individuelle Analyse, bietet aber eine erste Orientierung entlang der Teamanzahl.

1 Team → kein Framework nötig → 2–9 Teams → Nexus oder LeSS → 5–20 Teams → Scrum@Scale → Große Organisation → SAFe®

Diese Schwellenwerte überschneiden sich bewusst – die tatsächliche Wahl hängt nicht allein von der Teamanzahl ab, sondern ebenso von Unternehmenskultur, vorhandener Scrum-Erfahrung und dem Grad bestehender Governance-Anforderungen.

Welches Framework passt zu welcher Organisation?

Auch hier gilt: keine starre Regel, sondern eine Tendenz, die im Einzelfall geprüft werden sollte.

Organisationstyp	Häufig passende Tendenz
Start-up mit wenigen Teams	LeSS oder gar kein zusätzliches Framework
Mittelständisches Softwareunternehmen	Nexus
Konzern mit komplexer Produktlandschaft	SAFe®
Agiles Unternehmen mit organischem Wachstum	Scrum@Scale

Diese Tendenzen sind Orientierungspunkte, keine festen Regeln. Ein mittelständisches Unternehmen mit außergewöhnlich reifer agiler Kultur kann mit LeSS ebenso gut fahren wie ein Konzern in einer weniger regulierten Sparte mit Scrum@Scale.

Aufwand und Lernkurve im Überblick

Framework	Aufwand	Komplexität	Lernkurve
SAFe®	Hoch	Hoch	Steil
LeSS®	Mittel	Niedrig bis mittel	Moderat
Nexus®	Niedrig	Niedrig	Flach
Scrum@Scale	Mittel	Mittel	Moderat

Muss jedes Team dasselbe Framework nutzen?

Nein – und in der Praxis ist genau das eher die Ausnahme als die Regel. In größeren Organisationen arbeiten häufig unterschiedliche Teams mit unterschiedlichen Ansätzen nebeneinander: ein Entwicklungsteam nach Scrum, ein Betriebsteam nach Kanban, während die übergeordnete Koordination formal einem Skalierungsframework wie SAFe folgt. Entscheidend ist nicht, dass alle Teams identisch arbeiten, sondern dass die Schnittstellen zwischen ihnen – gemeinsame Releases, Abhängigkeiten, Kommunikationswege – klar definiert sind. Ein einheitliches Regelwerk auf Team-Ebene zu erzwingen, obwohl die Arbeit der Teams sehr unterschiedlich getaktet ist, schafft oft mehr Reibung, als es löst.

Migration zwischen Frameworks

Eine häufige Erwartung ist ein linearer Entwicklungspfad – etwa von Scrum über Nexus und LeSS bis zu SAFe, mit wachsender Unternehmensgröße. In der Praxis existiert dieser lineare Weg so nicht. Organisationen wechseln selten schrittweise von einem Framework zum nächsten; stattdessen wählen sie meist direkt das Framework, das zur aktuellen Situation passt, und passen es im Zeitverlauf an, statt es komplett auszutauschen. Ein Wechsel des Frameworks – etwa von Nexus zu SAFe bei starkem Wachstum – kommt vor, ist jedoch eher eine bewusste Neuausrichtung als eine automatische nächste Stufe, die jede wachsende Organisation zwangsläufig durchläuft.

Warum Scaling Agile oft scheitert

Über die konkreten Einführungsfehler hinaus lohnt sich der Blick auf die tieferliegenden, organisatorischen Ursachen, die Scaling-Initiativen häufig zum Stolpern bringen. Management, das formal Verantwortung an Teams delegiert, faktisch aber weiterhin zentral steuert, untergräbt jede noch so gut gewählte Struktur. Silos zwischen Abteilungen, die schon vor der Skalierung bestanden, verschwinden nicht durch ein neues Framework – sie zeigen sich nur in neuer Form. Fehlendes Vertrauen zwischen Teams führt dazu, dass Koordinationsmechanismen zu Kontrollinstrumenten werden, statt echte Zusammenarbeit zu ermöglichen. Und fehlende Produktorientierung – wenn Teams eher entlang technischer Komponenten als entlang echtem Kundennutzen organisiert sind – erschwert es, überhaupt sinnvoll teamübergreifend zu priorisieren, unabhängig davon, welches Framework formal im Einsatz ist.

Typische Fehler beim Skalieren

Zu früh skalieren. Ein Framework einzuführen, bevor die Grundlagen von Scrum in den einzelnen Teams tatsächlich funktionieren.
Zu viele Rollen. Zusätzliche Koordinationsrollen einführen, die mehr Abstimmungsaufwand erzeugen, als sie tatsächlich lösen.
Zu viele Meetings. Skalierung wird mit zusätzlichen Terminen verwechselt, statt mit besserer Koordination bestehender Arbeit.
Framework statt Kultur. Ein Rahmenwerk einführen, ohne die zugrunde liegende Zusammenarbeit und das gegenseitige Vertrauen zwischen Teams zu entwickeln.
Komplexität erhöhen, statt sie zu reduzieren. Ein Framework wird so umfassend umgesetzt, dass es mehr Fragen aufwirft, als es beantwortet.
Das Management bleibt unverändert. Dieselben Kontrollmechanismen wie vor der Skalierung bleiben bestehen, nur auf mehr Teams gleichzeitig angewendet.

Best Practices

Scrum zuerst beherrschen. Ein Skalierungsframework kann kein Team-Problem lösen, das schon vorher bestand.
Mit einem Pilot starten. Ein Framework zunächst mit wenigen Teams erproben, bevor es unternehmensweit ausgerollt wird.
Schrittweise skalieren. Struktur nach Bedarf ergänzen, statt von Anfang an das umfassendste verfügbare Modell zu übernehmen.
Transparenz erhöhen. Abhängigkeiten zwischen Teams sichtbar machen, bevor zusätzliche Koordinationsmechanismen eingeführt werden.
Communities of Practice etablieren. Informeller Wissensaustausch zwischen Teams ergänzt formale Koordination oft wirksamer, als weitere Prozesse es könnten.

Fazit

Scaling ist kein Selbstzweck. Wenn ein Scrum-Team bereits Probleme hat, werden diese Probleme mit zehn Teams meist größer, nicht kleiner. Skalierungsframeworks unterstützen die Zusammenarbeit zwischen bereits funktionierenden Teams – sie ersetzen keine agile Kultur, die im Kleinen noch nicht trägt.

Aus unserer Erfahrung

Das beste Skalierungsframework ist oft das einfachste, das tatsächlich zur Organisation passt – nicht das umfangreichste, das theoretisch alle Eventualitäten abdeckt. Unternehmen, die mit der schlankesten passenden Lösung starten, korrigieren erfahrungsgemäß leichter nach, als solche, die mit einem überdimensionierten Framework beginnen und es später wieder verschlanken müssen.

Möchten Sie den richtigen Weg für Ihre Organisation finden – vom einzelnen Scrum-Team bis zur Zusammenarbeit mehrerer Teams? Einen Überblick über alle Schulungen finden Sie in unserer Kategorie Scrum Schulungen.

Passende Scrum Schulungen

Weitere Fachartikel zum Thema Scrum

Grundlagen & Einführung

Rollen & Zusammenarbeit

Scrum im Arbeitsalltag

Zertifizierung, KI & Skalierung