"SAFe, LeSS, Nexus – Skalierung als Ausrede"

Oktober 2025 11 Min. Lesezeit Meinung + Berichtsreferenz

Wenn die Agile-Einführung einer Organisation nicht funktioniert, ist die Antwort selten, mehr Framework hinzuzufügen. Genau das tun aber die meisten Organisationen. Sie skalieren. Und Skalierung ist in den meisten Fällen keine Lösung des Problems. Es ist ein teurer, aufwendig dokumentierter Weg, ihm auszuweichen.

---

Der Einstieg: Das Skalierungsparadox

Hier ist eine Frage, die es wert ist, sich damit auseinanderzusetzen: Wenn ein einzelnes Scrum-Team in deiner Organisation Schwierigkeiten hat, konsistent Wert zu liefern – was lässt dich glauben, dass fünfzig durch ein Programme Increment Planning Event koordinierte Scrum-Teams es besser machen werden?

Die ehrliche Antwort ist in den meisten Fällen: nichts. Die Probleme, die ein Team ineffektiv machen – unklare Prioritäten, fehlende echte Product Owner-Autorität, Organisationsstrukturen, die Selbstorganisation behindern, Managementverhalten, das psychologische Sicherheit untergräbt – verschwinden nicht, wenn man ein Skalierungsframework hinzufügt. Sie multiplizieren sich. Aus der Dysfunktion eines Teams wird die Dysfunktion von fünfzig Teams – jetzt mit zusätzlichen Zeremonien, zusätzlichen Rollen und einer deutlich höheren Beratungsrechnung.

Das ist das Skalierungsparadox: Die Organisationen, die Skalierungsframeworks am aggressivsten einführen, sind häufig diejenigen, die die grundlegenden Probleme, die Skalierungsframeworks nicht lösen können, noch nicht gelöst haben.

---

Die Realität: Was Skalierungsframeworks wirklich tun

Seien wir präzise in dem, worüber wir sprechen. Die drei am häufigsten eingeführten Skalierungsframeworks sind:

Framework	Vollständiger Name	Herkunft	Marktposition
SAFe	Scaled Agile Framework	Dean Leffingwell, 2011	Am weitesten verbreitet, Enterprise-Fokus
LeSS	Large-Scale Scrum	Larman und Vodde, 2005	Organisatorisch anspruchsvoll, weniger verbreitet
Nexus	Nexus Framework	Scrum.org, 2015	Scrum-nativ, moderate Verbreitung

Jedes von ihnen adressiert ein echtes Problem: Wie koordiniert man mehrere Teams, die an einem einzigen Produkt oder verwandten Produkten arbeiten? Abhängigkeiten müssen verwaltet werden. Planung muss aufeinander abgestimmt werden. Architekturentscheidungen müssen koordiniert werden. Das sind echte Herausforderungen, die echte Lösungen verdienen.

Das Problem liegt nicht darin, dass Skalierungsframeworks existieren. Das Problem ist, warum die meisten Organisationen sie einführen – und wozu sie nach der Einführung tatsächlich verwendet werden.

Was die Daten zeigen

Der State of Agile Report ist hier aufschlussreich. Jahr für Jahr zeigt er SAFe als das dominierende Skalierungsframework nach Verbreitung – typischerweise verwendet von 30–40 % der Organisationen, die einen Skalierungsansatz eingeführt haben. Er zeigt auch konsistent, dass zu den Hauptgründen für die Einführung von Skalierungsframeworks folgende gehören:

• Konsistenz über Teams hinweg – ein legitimes Ziel, das oft aus illegitimen Gründen verfolgt wird
• Verbesserte Transparenz – häufig ein Code für „das Management will mehr Berichte”
• Bessere Ausrichtung – echtes Bedürfnis, aber Ausrichtung wovon genau, und in wessen Richtung?
• Executive Mandate – der am wenigsten ermutigende Grund von allen

„Executive Mandate” verdient besondere Aufmerksamkeit. Wenn ein Skalierungsframework eingeführt wird, weil eine Führungskraft eine Konferenz besucht hat, oder weil eine Beratungsfirma es empfohlen hat, oder weil ein Wettbewerber es verwendet – wird das Framework als Signal genutzt, nicht als Lösung. Es signalisiert organisatorische Reife, strategische Absicht und Modernität. Es liefert davon in sich selbst keines.

---

Der Checksum: Eine Framework-für-Framework-Bewertung

SAFe – Das Enterprise-Comfort-Food

SAFe ist das kommerziell erfolgreichste Skalierungsframework aus einem bestimmten Grund: Es ist dasjenige, das am wenigsten organisatorischen Wandel erfordert, während es so aussieht, als würde es den meisten erfordern. Es fügt Rollen hinzu – Release Train Engineer, Business Owner, Solution Architect. Es fügt Zeremonien hinzu – PI Planning, System Demo, Inspect and Adapt. Es fügt Artefakte hinzu – Program Increment, Solution Backlog, Architectural Runway. All das sitzt oben auf bestehenden Organisationsstrukturen, statt sie zu ersetzen.

Das ist SAFes kommerzielles Genie und seine strukturelle Schwäche zugleich. Es ist einführbar genau deshalb, weil es Organisationen nicht dazu zwingt, die Hierarchie, die Governance-Strukturen oder das Managementverhalten aufzugeben, das häufig die Probleme verursacht, die sie zu lösen versuchen. Man kann SAFe einführen, ohne dass ein einziger Führungsmanager seine Entscheidungsfindung verändert. Und die meisten Organisationen tun genau das.

Der SAFe-Test: Frage eine SAFe-implementierende Organisation, ob ihre Entwicklungsteams echte Autorität haben, technische Entscheidungen ohne Managementgenehmigung zu treffen. Frage, ob Prioritäten innerhalb eines Programme Increments auf Basis neuer Erkenntnisse geändert werden können. Frage, ob irgendein Teil der bestehenden Managementhierarchie im Zuge der SAFe-Einführung eliminiert wurde. Die Antworten werden dir sagen, ob du eine echte Transformation oder ein teures Rebranding vor dir hast.

Um fair gegenüber SAFe zu sein: Mit echten Absichten und echtem organisatorischem Wandel implementiert, kann es funktionieren. Ich habe es funktionieren sehen. Das Framework selbst ist nicht das Problem. Das Problem ist, dass es fast nie mit echten Absichten und echtem organisatorischem Wandel implementiert wird. Die Organisationen, die es am meisten brauchen, sind diejenigen, die am wenigsten bereit sind, das zu tun, was es wirklich erfordert.

LeSS – Das ehrliche Framework

LeSS verdient mehr Anerkennung als es bekommt. Im Gegensatz zu SAFe ist es explizit darüber, welchen organisatorischen Wandel es erfordert. Es gibt an, dass die meisten Spezialrollen eliminiert werden sollten. Es erfordert einen einzigen Product Owner für das gesamte Produkt mit echter Autorität. Es fordert, dass Teams wirklich cross-funktional und selbstverwaltend sind. Es eliminiert die mittleren Managementebenen, die typischerweise zwischen Teams und Produktstrategie existieren.

Deshalb ist die LeSS-Adoption relativ selten. Nicht weil es nicht funktioniert – die Belege deuten darauf hin, dass es gut funktioniert, wenn es ordentlich implementiert wird. Aber weil die ordentliche Implementierung von Organisationen verlangt, Dinge aufzugeben, die die meisten Organisationen nicht bereit sind aufzugeben: Managementebenen, Spezialsilos und die bequeme Fiktion, dass Koordinationsprobleme durch das Hinzufügen von Koordinationsrollen gelöst werden können.

„LeSS ist das Skalierungsframework, das Organisationen die Wahrheit über das sagt, was Skalierung erfordert. SAFe ist dasjenige, das ihnen sagt, was sie hören wollen. Der Markt hat seine Präferenz klar gemacht.” Markus – agile-checksum.com

Nexus – Der pragmatische Mittelweg

Nexus liegt zwischen SAFe und LeSS hinsichtlich Komplexität und organisatorischen Anforderungen. Es ist Scrum-nativ – explizit auf Scrum aufgebaut statt daneben – und fügt eine einzige Integrationsebene hinzu: das Nexus Integration Team, das dafür verantwortlich ist, Abhängigkeiten zu koordinieren und integrierte Increments über drei bis neun Scrum-Teams hinweg sicherzustellen.

Nexus ist ehrlich über seinen Umfang. Es adressiert das spezifische Problem mehrerer Scrum-Teams, die an einem einzigen Produkt arbeiten. Es versucht nicht, ein Enterprise-Betriebsmodell zu sein. Für Organisationen, die wirklich drei bis neun Scrum-Teams an einem einzigen Produkt koordinieren müssen und die grundlegenden Scrum-Probleme auf Teamebene bereits gelöst haben, ist Nexus wahrscheinlich die pragmatischste verfügbare Wahl.

Der Haken: Die meisten Organisationen, die Nexus einführen, haben die grundlegenden Scrum-Probleme auf Teamebene nicht gelöst. Sie skalieren Dysfunktion, nicht Fähigkeit.

---

Praxisbeispiele: Skalierung, die schiefgelaufen ist

Die SAFe-Implementierung, die nichts verändert hat

Eine große Finanzdienstleistungsorganisation, mit der ich zusammengearbeitet habe, führte SAFe über einen Zeitraum von achtzehn Monaten ein. Das Transformationsprogramm kostete mehrere Millionen Euro, umfasste eine externe Beratung und führte zu einer vollständigen SAFe-Implementierung über zwölf Teams und drei Agile Release Trains.

Zwei Jahre nach der Implementierung wurde ich hinzugezogen, um zu bewerten, warum sich die Lieferperformance nicht verbessert hatte. Die Bewertung war nicht kompliziert. Die zwölf Teams erhielten ihre Prioritäten immer noch von einem Portfolio-Management-Komitee, das monatlich tagte. Die Release Train Engineers hatten keine Autorität, Prioritäten innerhalb eines Programme Increments auf Basis neuer Erkenntnisse zu ändern. Die PI Planning Events waren aufwendige Zeremonien, die Entscheidungen formalisierten, die bereits in Pre-PI-Planning-Meetings getroffen worden waren. Die Managementhierarchie war identisch mit derjenigen, die vor SAFe existiert hatte. Das Vokabular hatte sich geändert. Sonst nichts.

Als ich diese Erkenntnisse präsentierte, fragte mich ein leitender Manager, was ich empfehle. Ich sagte ihm: Hört auf mit SAFe, behebt den Priorisierungsprozess, gebt den Teams echte Autorität und eliminiert zwei Managementebenen. Er sagte mir, das sei nicht realistisch. Ich stimmte zu, dass es in ihrer aktuellen Kultur nicht realistisch sei. Ich sagte ihm auch, dass ihnen ohne diese Änderungen kein Framework helfen werde. Wir haben nicht mehr zusammengearbeitet.

Der LeSS-Versuch, der aufgegeben wurde

Eine Produktorganisation versuchte eine LeSS-Implementierung. Sie kamen bis zur Definition des einzelnen Product Backlogs und der Identifizierung der Notwendigkeit, drei mittlere Managementrollen zu eliminieren, bevor das Programm stillschweigend eingestellt wurde. Der offizielle Grund war „organisatorische Bereitschaft”. Der eigentliche Grund war, dass die drei Manager, deren Rollen eliminiert werden sollten, politisch einflussreich genug waren, um die Implementierung unhaltbar zu machen.

Das ist keine Kritik an LeSS. Es ist eine Illustration dessen, warum echte Skalierung politisch schwierig ist – auf eine Art, die die Framework-Dokumentation selten anerkennt.

Das Nexus, das versehentlich zu SAFe wurde

Ein Softwareunternehmen implementierte Nexus für fünf Teams, die an einer einzigen Plattform arbeiteten. Innerhalb von achtzehn Monaten war das Nexus Integration Team von vier auf zwölf Personen gewachsen. Es hatte sein eigenes Backlog, seine eigenen Zeremonien und seine eigene Berichtslinie entwickelt. Es war de facto zu einem Programm-Management-Büro mit Agile-Vokabular geworden. Die Koordinationsschicht, die leichtgewichtig sein sollte, war zum schwersten Teil der Organisation geworden.

Das passiert, weil Koordinationsrollen Arbeit anziehen. Gib einer Gruppe von Menschen die Verantwortung für Integration, und sie werden mehr Dinge finden, die zu integrieren sind. Das Gegenmittel – strikte WIP-Limits für die Koordinationsebene selbst und ein klares Mandat, sich schrittweise weniger notwendig zu machen – wird selten angewendet.

---

Wann Skalierung wirklich sinnvoll ist

Ich möchte klarstellen: Ich argumentiere nicht kategorisch gegen Skalierungsframeworks. Ich argumentiere gegen die Verwendung als Ersatz für die Lösung von Problemen, die sie nicht lösen können.

Skalierung macht Sinn, wenn all das Folgende zutrifft:

• Einzelne Teams sind wirklich effektiv – sie selbstorganisieren sich, liefern konsistent, verbessern sich kontinuierlich. Wenn Teams auf Teamebene nicht effektiv sind, wird Skalierung sie nicht verbessern.
• Das Koordinationsproblem ist real – mehrere Teams können wirklich nicht unabhängig liefern, wegen geteilter Architektur, geteiltem Codebase oder echter Abhängigkeiten zwischen Teams. Nicht jede Multi-Team-Umgebung hat dieses Problem.
• Die Organisation ist bereit, sich zu verändern – nicht nur ein Framework auf bestehende Strukturen aufzusetzen, sondern tatsächlich zu verändern, wie Entscheidungen getroffen, Prioritäten gesetzt und Autorität verteilt wird.
• Die Führung versteht, worauf sie sich einlässt – kein Transformationsprogramm mit einem definierten Enddatum, sondern eine dauerhafte Veränderung der Arbeitsweise der Organisation.

Die ehrliche Diagnose: Stelle vor der Einführung eines Skalierungsframeworks diese Frage in einem Raum voller Führungskräfte und beobachte die Reaktionen: „Sind wir bereit, Managementrollen zu eliminieren, wenn das Framework es erfordert?” Wenn die Antwort nicht ein klares Ja ist – stopp. Du bist noch nicht bereit zu skalieren. Behebt zuerst die Kultur.

---

Das Fazit: Skaliere die Lösung, nicht das Problem

Skalierungsframeworks sind Werkzeuge. Wie alle Werkzeuge sind sie im richtigen Kontext nützlich und im falschen kontraproduktiv. Der richtige Kontext für ein Skalierungsframework ist eine Organisation, die die grundlegenden Probleme von Agile auf Teamebene gelöst hat und wirklich mehrere Teams an einem komplexen Produkt koordinieren muss. Diese Beschreibung trifft auf weniger Organisationen zu, als der Markt für Skalierungsframeworks vermuten lässt.

Für die meisten Organisationen, die derzeit Skalierungsframeworks einführen oder in Betracht ziehen, ist die ehrliche Diagnose einfacher und unbequemer: Das Problem ist nicht, dass du eine bessere Koordination zwischen Teams brauchst. Das Problem ist, dass einzelne Teams nicht die Autorität, die Klarheit oder das Vertrauen haben, das sie brauchen, um effektiv zu sein. Kein Skalierungsframework adressiert diese Probleme. Nur Führung tut es.

Führe den Checksum durch, bevor du skalierst:

1. Kann jedes deiner Teams seinen Sprint Goal gerade jetzt nennen, ohne nachzuschauen?
2. Kann jeder Product Owner eine Priorität ändern, ohne eine Genehmigung von jemandem außerhalb des Teams einzuholen?
3. Wurde eine Managementebene eliminiert – oder wirklich verändert – als Teil deiner Agile-Einführung?

Wenn die Antworten nein, nein und nein sind – hast du kein Skalierungsproblem. Du hast ein Fundament-Problem. Bau zuerst das Fundament.

---

In diesem Artikel verwendete Glossarbegriffe

• SAFe – Scaled Agile Framework, das am weitesten verbreitete Enterprise-Skalierungsframework.
• LeSS – Large-Scale Scrum, ein Skalierungsframework, das erheblichen organisatorischen Wandel erfordert.
• Scrum – Ein leichtgewichtiges Framework zur Entwicklung und Lieferung komplexer Produkte.
• Product Owner – Die Scrum-Verantwortlichkeit, die für die Maximierung des Produktwerts zuständig ist.
• Agile Transformation – Der Prozess, durch den eine Organisation Agile-Werte und -Praktiken im großen Maßstab einführt.
• Psychological Safety – Die gemeinsame Überzeugung, dass es sicher ist, zwischenmenschliche Risiken innerhalb eines Teams einzugehen.