Agile Scaling Frameworks: Warum SAFe, LeSS & Co. ohne Decision-OS nur mehr Meetings skalieren
Scaling-Frameworks wirken wie ein Rettungsring für Komplexität. In der Praxis skalieren sie oft nur Abstimmung. Der Engpass bleibt derselbe: unklare Decision Rights, falsche Foren und Entscheidungen ohne Owner.
Scaling-Frameworks sind nicht das Problem - aber sie lösen das falsche zuerst
Es gibt eine Phase in wachsenden Organisationen, in der sich alles gleichzeitig verschiebt: Abhängigkeiten steigen, Schnittstellen werden dichter, Prioritäten konkurrieren stärker, und die Zahl der Beteiligten pro Entscheidung explodiert. Genau in dieser Phase tauchen Begriffe wie SAFe, LeSS, Nexus, Spotify, Flight Levels oder „Agile at Scale“ auf der Agenda auf. Das Versprechen ist verlockend: Wenn wir uns nur auf ein Skalierungs-Framework einigen, wird es wieder geordnet, planbar und schnell.
Das Problem ist nicht das Framework. Das Problem ist die Reihenfolge. Viele Organisationen greifen zuerst nach Prozess - obwohl ihr eigentlicher Engpass Entscheidung ist. Und wenn Entscheidung der Engpass ist, skaliert Prozess nicht Wirkung, sondern Abstimmung.
Merksatz: Wenn du Governance nicht zuerst klärst, skaliert ein Framework vor allem Kalenderzeit.
1) Warum Scaling-Frameworks so verführerisch sind
Scaling-Frameworks kommen meist genau dann ins Spiel, wenn sich Komplexität „nicht mehr wie Wachstum“ anfühlt, sondern wie Reibung. Teams sind voller Energie, aber sie blockieren sich gegenseitig. Roadmaps werden politisch. Bugs, Tech Debt und Prioritäten kollidieren. Der Wunsch nach Ordnung ist legitim. Und Frameworks liefern Ordnung als Paket: Rollen, Events, Artefakte, Taktung, Begriffe.
Der psychologische Effekt ist stark: Ein Framework gibt das Gefühl, endlich „den Hebel“ gefunden zu haben. Und weil andere große Organisationen es auch benutzen, entsteht der Eindruck: Das ist der professionelle Weg.
Nur: Professionell ist nicht, ein Framework zu wählen. Professionell ist, den Engpass zu erkennen.
2) Der typische Fehlschluss: „Mehr Prozess = mehr Alignment“
Wenn Reibung steigt, wird Alignment zur Droge. Man fühlt sich besser, wenn alle im Meeting waren. Man fühlt sich sicherer, wenn alle einverstanden nicken. Und man fühlt sich verantwortungsvoller, wenn man Entscheidungen „gemeinsam getragen“ hat.
In der Praxis heißt das: Mehr Gremien, mehr Syncs, mehr Pre-Reads, mehr Abstimmungsrunden. Das wird oft als Reife verkauft. Tatsächlich ist es häufig nur Unsicherheit, die sich in Prozess verkleidet.
Alignment ist nicht per se schlecht. Aber Alignment ist teuer. Und wenn Alignment nicht sauber gegen Geschwindigkeit und Verantwortung balanciert wird, gewinnt Alignment immer. Ergebnis: Meetings wachsen schneller als Entscheidungen.
3) Der harte Kern: Entscheidungen sind der Engpass
Scaling scheitert selten daran, dass Teams nicht liefern könnten. Es scheitert daran, dass sie nicht entscheiden können. Entscheidungen hängen in unklaren Verantwortlichkeiten, in unklaren Foren, in Machtfragen, in fehlenden Kriterien oder in „wir müssen noch mal drüber reden“.
Das zeigt sich besonders in drei Kennzahlen, die man in fast jedem wachsenden Setup findet:
- Time-to-Decision (TtD): Wie lange dauert es vom Auftauchen eines Entscheidungspunkts bis zum finalen Beschluss?
- Reopen-Rate: Wie oft wird eine Entscheidung wieder aufgerollt, obwohl sie formal „entschieden“ war?
- Meeting-Output: Wie viele klare Beschlüsse pro Meeting-Stunde entstehen wirklich?
Wenn diese drei Werte schlecht sind, ist das kein Prozessproblem. Dann ist das ein Governance-Problem.
4) Warum SAFe oft nach „mehr Meetings“ riecht
SAFe wird oft als Schwergewicht wahrgenommen: viele Rollen, viele Events, viel Cadence. Das kann sinnvoll sein, wenn die Organisation bereit ist, Entscheidungen in klaren Foren zu treffen. Wenn nicht, erzeugt SAFe schnell genau das, was viele ohnehin schon haben: Kalender voll, Köpfe voll, Entscheidungen offen.
Das ist kein SAFe-Bashing. Es ist die Beobachtung: Wenn du keine Decision Rights hast, wird jede SAFe-Veranstaltung zur Bühne für Politik. Dann ist PI Planning nicht Planungsdisziplin, sondern Interessenausgleich. Dann ist das ART nicht ein Liefermodell, sondern ein neues Gremium. Und dann werden die Meetings nicht weniger, sondern „nur offiziell“.
5) Warum LeSS oft an Machtfragen scheitert
LeSS ist in vieler Hinsicht radikaler: weniger Rollen, mehr Fokus auf echte Produktorganisation, weniger Management-Theater. Das macht LeSS attraktiv für Menschen, die Overhead hassen. Gleichzeitig macht es LeSS schwierig für Organisationen, die noch nicht geklärt haben, wer welche Entscheidungshoheit wirklich hat.
Wenn Machtfragen ungeklärt sind, werden sie nicht durch ein schlankes Framework gelöst. Sie werden nur sichtbarer. LeSS scheitert dann nicht an Methode, sondern an fehlender Entscheidungsklarheit: „Wer priorisiert wirklich?“, „Wer entscheidet bei Konflikt?“, „Welches Forum ist final?“
6) Das Minimal-Setup, das jedes Scaling-Framework erst wirksam macht
Bevor man ein Framework „ausrollt“, braucht man ein Entscheidungssystem. Das ist der Teil, den viele überspringen. Und genau deshalb ist der Return on Framework oft enttäuschend.
Dieses Minimal-Setup ist nicht glamourös, aber es ist wirksam:
- Decision Rights (DRI oder RACI): Für typische Entscheidungskategorien muss klar sein, wer final entscheidet. Nicht wer „beteiligt“ ist.
- Foren-Design: Welche Entscheidungen passieren operativ, welche taktisch, welche strategisch? Und welches Forum ist für welche Kategorie final?
- Decision-Log: Jede relevante Entscheidung wird dokumentiert - Owner, Datum, Kontext, Annahmen, Termin. Das reduziert Reopen-Rate und Politik.
- Meeting-Kill: Eine Liste von Meetings, die ersatzlos gestrichen oder asynchron ersetzt werden. Das setzt sofort Kapazität frei.
- Messung: TtD, Reopen-Rate, Meeting-Output. Nicht als Reporting-Theater, sondern als Feedback für Governance.
Pragmatisch: Wenn ihr nur eine Sache macht: Klärt Decision Rights für die Top-10 Entscheidungstypen. Ihr werdet sofort weniger eskalieren.
7) Decision-OS: Governance-Layer statt Framework-Krieg
Viele Diskussionen um Scaling-Frameworks laufen wie Religionskriege. Scrum vs. SAFe, LeSS vs. Spotify, „wir brauchen mehr Prozess“ vs. „wir brauchen weniger Prozess“. Der Punkt ist: Das ist nicht die eigentliche Frage.
Die eigentliche Frage ist: Wie treffen wir Entscheidungen, und wie bleibt es danach verbindlich?
Decision-OS ist genau dafür gedacht: als Governance-Layer über Methoden. Tool-neutral. Framework-agnostisch. Es macht bestehende Arbeitsweisen anschlussfähig, indem es Entscheidungsräume klärt, Foren definiert, Entscheidungen dokumentiert und Wirkung messbar macht.
8) Ein praktisches Bild: Der „Entscheidungs-Stack“
Stell dir Scaling wie einen Stack vor:
- Unten: Decision Rights und Foren (wer entscheidet wo?)
- Mitte: Decision-Log und Cadence (wie bleibt es sichtbar und verbindlich?)
- Oben: Methode und Delivery (Scrum, SAFe, LeSS, Kanban)
Viele Organisationen drehen den Stack um. Sie fangen oben an. Dann wundern sie sich, warum sie zwar neue Rituale haben, aber die gleiche Langsamkeit.
9) Wenn ihr trotzdem SAFe oder LeSS wollt: So bleibt es vendor-neutral anschlussfähig
Es ist völlig legitim, SAFe oder LeSS einzusetzen. Entscheidend ist, dass ihr Governance nicht delegiert. Ein Framework kann nicht für euch entscheiden. Ein Coach kann nicht eure Decision Rights klären. Das muss im Team verankert sein.
Der saubere Weg ist: Erst Governance-Minimum, dann Framework-Anschluss. Konkret heißt das:
- Definiert eure Entscheidungskategorien (Produkt, Architektur, Budget, Personal, Risiko).
- Setzt Owner (DRI) und klare Foren (finale Entscheidungsorte).
- Startet ein Decision-Log und ein wöchentliches Review für Reopen-Fälle.
- Kürzt Meetings durch Meeting-Kill, bevor ihr neue Events einführt.
- Messt TtD, Reopen-Rate, Meeting-Output als Feedback.
10) Fazit
Agile Scaling Frameworks sind keine Zauberformel. Sie sind Strukturangebote. Ob sie wirken, hängt davon ab, ob eure Organisation Entscheidungen schnell und sauber treffen kann. Wenn ihr das Minimal-Setup aus Decision Rights, Foren, Decision-Log und Messung etabliert, werden Frameworks leichter, wirksamer und weniger politisch. Wenn nicht, skaliert ihr vor allem Meetings.
Wenn ihr genau das vermeiden wollt, lohnt sich der Einstieg über Decision-OS Tools oder über einen Workshop-Pfad aus Seminare & Workshops. Und wenn ihr direkt Klarheit wollt: Ein 20-Minuten-Call reicht, um Engpass, Modul und Starttermin festzulegen.
Agile Scaling Frameworks: SAFe, LeSS und der Engpass Entscheidung
Viele Unternehmen suchen nach „Agile Scaling Frameworks“, weil Wachstum plötzlich nach Reibung aussieht: mehr Abhängigkeiten, mehr Stakeholder, mehr Abstimmung. Frameworks wie SAFe oder LeSS bieten Struktur, Rollen und Taktung. Was sie nicht automatisch liefern, ist Entscheidungsfähigkeit. Wenn Decision Rights unklar sind, wird jedes Event zur Verhandlung und jedes Meeting zur Schleife.
Der wirksamere Ansatz ist Governance-first: klare Owner (DRI oder RACI), passende Foren für unterschiedliche Entscheidungstypen und ein Decision-Log, das Verbindlichkeit schafft. Ergänzt um eine kleine Messung - Time-to-Decision, Reopen-Rate und Meeting-Output - wird sichtbar, ob ein Framework Entscheidungen schneller macht oder nur Kalender füllt. In vielen Setups ist die Reihenfolge entscheidend: Erst Governance-Minimum, dann Framework-Anschluss. So bleibt ihr vendor-neutral und verhindert, dass ihr „mehr Prozess“ skaliert, statt Wirkung.
Wenn ihr SAFe oder LeSS einsetzen wollt, beginnt nicht mit Rollen und Ritualen, sondern mit Entscheidungskategorien, Ownern und finalen Foren. Danach sind Methoden leicht anschlussfähig. Mehr Kontext findet ihr im Bereich Decision-OS und in den Decision-OS Tools.