Die Wahrheit über agile Skalierung: SAFe, LeSS oder gar nichts?

Immer mehr Unternehmen fragen sich: Wie skaliere ich Agilität jenseits einzelner Teams, ohne in neue Gefahren zu tappen? Moderne Skalierungsframeworks wie SAFe oder LeSS versprechen, agile Prinzipien in große Organisationen zu tragen. Doch Kritiker warnen schon lange: SAFe etwa wirke eher wie ein starres Phasenmodell unter dem Deckmantel von Agilität . Tatsächlich heißt es: Die vielen Hierarchieebenen und Abläufe in solchen Frameworks fressen oft genau die Agilität auf, die sie angeblich ermöglichen sollen . Entscheider:innen müssen sich deshalb fragen, wann diese Rahmen wirklich helfen – und wann sie bloß zusätzliche Bürokratie erzeugen.

Warum immer mehr Unternehmen auf agile Skalierung setzen

Unternehmen stehen heute unter enormem Druck: Volatile Märkte, digitale Disruption und immer komplexere Produkte erfordern Flexibilität und Tempo. Agilität gilt als Ausweg, weil sie erlaubt, schneller auf Veränderungen zu reagieren und den Fokus konsequent auf den Kundennutzen zu legen. In kleinen Teams funktioniert das schon lange gut – und viele Manager wünschen sich dieselben Effekte im Großformat. Studien legen nahe, dass das kein leeres Versprechen ist: Agile Unternehmen wachsen nachweislich schneller. „75 Prozent der Unternehmen mit hoher Agilität berichten von einem Umsatzwachstum von mindestens 5 Prozent im Jahresvergleich, gegenüber nur 29 Prozent bei geringer Agilität“ . Noch deutlicher: Forschungen zeigen, dass eine agile Transformation die Produkteinführungszeit um rund 40 Prozent verkürzen kann . Kein Wunder also, dass Vorstände auf den fahrenden Zug aufspringen und agile Skalierung als einen Schlüssel zu Innovation und Effizienz sehen.

• Wettbewerbs- und Innovationsdruck: In dynamischen Märkten sind schnelle Reaktionen essenziell. Agile Skalierung soll helfen, Innovation über das ganze Unternehmen zu verteilen: Teams lernen voneinander, teilen Wissen und arbeiten synchron auf gemeinsame Ziele hin .

• Geschwindigkeit und Time-to-Market: Agilität gilt als Weg, Produkte deutlich schneller auf den Markt zu bringen . Der Fokus auf kurze Iterationen und Kundenfeedback kann Entwicklungszyklen drastisch verkürzen und so Umsatzchancen schneller nutzen helfen.

• Qualität und Kundenorientierung: Agiles Arbeiten erhöht nachweislich die Produktqualität und Kundenzentrierung, weil Teams früh Feedback einholen und inkrementell liefern . Transparenz über Anforderungen und ein hohes Maß an Selbstorganisation sollen helfen, Fehlentwicklungen früh abzufangen.

• Organisatorische Komplexität: Große Organisationen haben viele Abteilungen, Produkte und technische Abhängigkeiten. Skalierungsframeworks versprechen, genau hier Orientierung zu schaffen: Sie strukturieren Arbeit über Teamgrenzen hinweg und sollen Teams, Fachbereiche und Management auf ein gemeinsames Ziel einschwören .

So entsteht bei vielen die Idee: Wenn drei oder fünf agile Teams gut funktionieren, müsste das doch auch bei 50 oder 100 Teams gehen – wenn man nur den richtigen Rahmen wählt. Doch genau hier beginnt der Knackpunkt.

Was SAFe, LeSS & Co. versprechen – und was sie wirklich leisten

Die großen Frameworks haben alle eins gemeinsam: Sie wollen Agilität zum Betriebsmodell für die ganze Organisation machen – indem sie Rollen, Events und Artefakte in fest definierte Ebenen gießen. Jeder Anbieter preist seine Lösung als „Enterprise-OS“ an. SAFe (Scaled Agile Framework) etwa bewirbt sich damit, „komplexe Systeme mit einer hohen Anzahl von Teams und vielen Abhängigkeiten zu unterstützen“, und großen Organisationen, die noch nicht agil sind, die Chance zu geben, dauerhaft agil zu arbeiten . In der Praxis bedeutet das: SAFe führt Ebenen für Programm- und Portfolio-Planung ein und fügt viele neue Rollen (Release Train Engineer, System Architekten, Solution Owner usw.) und regelmäßige Groß-Events (z.B. Program Increment Planning) hinzu. Theoretisch schafft dies Transparenz von der Strategie bis ins Team.

LeSS (Large Scale Scrum) hingegen folgt einem anderen Versprechen: Weniger ist mehr. In seiner Basisvariante gilt LeSS für etwa acht Scrum-Teams und baut direkt auf bestehenden Scrum-Prinzipien auf. Nur ein oder wenige Product Owner steuern die Arbeit, es gibt keine neue Management-Hierarchie. LeSS hebt vor allem die Orientierung an agilen Grundprinzipien hervor und betont Einfachheit. Typischerweise heißt es über LeSS: Die geringe Komplexität und starke Ausrichtung auf die agilen Werte sei sein größter Vorteil .

Und Nexus (von Scrum.org) macht es noch einen Schritt minimalistischer: Es fügt nur ein zusätzliches Integrationsteam hinzu, das die Arbeit von bis zu neun parallelen Scrum-Teams synchronisieren soll. Hier liegt der „große Vorteil“ vor allem in einem schlanken Aufbau mit sehr geringem Formalisierungsgrad . Nexus will nur bei wirklich vielen Teams helfen, in dem es ein paar Absprachen ergänzt – dafür verlangt es umso mehr Eigeninitiative.

Natürlich versprechen sich alle Frameworks von ihrem Ansatz klare Vorteile. Doch die Realität sieht oft anders aus. In der Praxis zeigt sich:

• SAFe liefert zwar einen reichhaltigen Werkzeugkasten für Planung und Reporting. Ein großer Mehrwert kann entstehen, wenn wirklich Hunderte von Entwickler:innen koordiniert werden müssen. So loben Anbieter, SAFe böte „großen Organisationen […] die Chance, dauerhaft agil zu arbeiten“ . Gleichzeitig beklagen Praktiker, dass SAFe sehr unflexibel sei: „Die hierarchische Struktur frisst Agilität“, heißt es etwa in einer Analyse . Viele Ebenen, starre Rituale und rollenspezifische Checklisten führen leicht zu mechanistischen Prozessen. Agiles Mindset und Kundenfokus treten dabei manchmal in den Hintergrund, weil Teams nur noch ihren Planungen hinterher arbeiten. Zudem fehlt in SAFe oft eine klare End-to-End-Verantwortung – Teams liefern Features, aber niemand sorgt dafür, dass daraus echte Kundennutzenprodukte werden .

• LeSS verfolgt das Gegenteil: So wenig Neues wie möglich einzuführen klingt sinnvoll, kostet aber bei großer Ausdehnung seinen Preis. In einem Mittelstand mit wenigen Dutzend Entwicklern kann LeSS sehr schnell die Agile-Werte stärken und eine echte Teamorientierung fördern. Bei extremen Größen (mehrere hundert Entwickler) wird LeSS als „radikaler Ansatz“ allerdings schnell unbequem: Die Einführung in sehr großen Konzernen ist schwierig , und es fehlt eine Bündelung auf der Strategieebene. Kurzum: LeSS funktioniert fantastisch, solange man im mittleren Bereich bleibt , verliert aber den Grip, wenn Dependencies und Größen exponentiell wachsen.

• Nexus punktet durch Einfachheit: Es arbeitet wie gesagt mit minimalem Overhead. Doch viele Anwender berichten, dass diese Minimalität auch ein Nachteil sein kann. Weil Nexus praktisch keine Leitplanken für Strategie- oder Architekturentscheidungen vorgibt, müssen Organisationen vieles selbst erarbeiten. In der Praxis ist Nexus deshalb deutlich seltener zu finden als SAFe oder LeSS . Manch einer stuft es daher als Eigenbau-Fundament ein: Es bietet nur das Gerüst, geübt muss man es selbst mit Leben füllen .

Zusammengefasst: Die Skalierungs-Frameworks werben alle damit, die Agilität über viele Teams zu organisieren. In der Realität tauschen sie jedoch oft einen Mangel an Agilität (Unkoordiniertheit) gegen ein Übermaß an Prozessen ein. Entscheidend ist, was nachher übrigbleibt: echte Selbstorganisation – oder nur ein neuer, großer Planungsapparat.

Typische Probleme und Nebenwirkungen von Skalierungsframeworks

Selbst mit den besten Absichten stoßen viele Unternehmen beim Ausrollen von SAFe, LeSS & Co. auf ähnliche Stolpersteine. Klassische Probleme sind:

• Prozess-Overhead und Bürokratie: Jeder zusätzliche Rollen- und Meeting-Radar führt zu mehr Abstimmungsaufwand und längeren Planungszyklen. Kritiker:innen bemängeln an SAFe, dass es viele Hierarchieebenen mit festen Terminen einführe – wodurch die „hierarchische Struktur Agilität frisst“ . Ähnlich klagen Anwender über LeSS-Implementierungen, dass Scrum-of-Scrums und mangelnde Entscheidungen schnell die Schlagkraft verringern. Das Ergebnis kann sein, dass Teams mehr Zeit mit Reportings verbringen als mit echter Produktentwicklung.

• Missverständnisse und Scheinagilität: Manche Führungskräfte glauben, Agilität beginne und ende mit dem Framework. Sie führen pünktlich alle Scrum-Events ein, ohne aber die zugrundeliegenden Werte zu leben. Das führt schnell zum typischen Satz: „Wir arbeiten jetzt agil, aber werden nicht schneller“ . Ein häufiger Fehler ist, Agilität nur partiell einzuführen – etwa in einigen Pilot-Teams oder rein methodisch – und zu erwarten, dass dann der gewünschte Effekt „von alleine“ überspringt . In Wahrheit erfordert Agilität einen tiefen Kulturwandel: Offenheit, Lernen aus Fehlern und Kundenfokus sind keine Plugins, die man einfach aktivieren kann. Wird dieser Kulturwandel vernachlässigt, bleibt oft nur der Schein von Agilität.

• Mikromanagement statt Empowerment: Ironischerweise müssen agile Teams laut Framework große Freiheiten bekommen. In der Praxis beobachten viele jedoch, dass Manager agile Rituale als zusätzliche Kontrollinstanz nutzen. Anstatt Teams zu befähigen, werden Roadmaps und Backlogs noch stärker zentral gesteuert. Das wiederum verstärkt das Gefühl der „Scheinagilität“. So kritisieren Agile-Vordenker wie Jeff Gothelf, dass SAFe in vielen Fällen vor allem die Illusion vermittelt, agil zu sein, während in Wahrheit noch klassische Top-down-Planung läuft .

• Mangelnde Anpassung ans Unternehmen: Kein Framework kommt als universeller Einheitsbrei daher, doch zu oft wird es genau so angewendet – ohne eigene Anpassung. Wer versucht, ein Framework 1:1 zu implementieren, übersieht schnell wichtige Unternehmensbesonderheiten: unterschiedliche Reifegrade in den Teams, variierende Produktkomplexität oder kulturelle Widerstände. Anstatt echte Probleme zu lösen, baut man dann ein Isolationsgebilde auf, das vielleicht schön aussieht, aber interne Spannungen und Ineffizienzen nur überdeckt.

Fazit: Die Skalierung eines einzigen agile Teams auf ganze Divisionen birgt allerlei Fettnäpfchen. Zu viel Governance kann genauso schaden wie zu wenig Koordination. Deshalb gilt: Wer skaliert, braucht Augenmaß.

Wann skalierende Frameworks sinnvoll sind – und wann sie eher schaden

Es gibt keine allgemeingültige Antwort, aber einige Faustregeln helfen bei der Entscheidung:

• Wenn Mehrere Teams tatsächlich dasselbe Produkt entwickeln: Skalierung lohnt sich vor allem, wenn wirklich viele Teams an einem gemeinsamen Produkt oder Wertstrom arbeiten. Bei einem einzelnen Team hilft kein überbordendes Framework; ab etwa sieben bis zehn Scrum-Teams, die eng zusammenpassen müssen, kann ein Rahmen nützlich werden. SAFe etwa ist explizit für sehr große Umfänge konzipiert . LeSS wiederum wurde für kleine bis mittelgroße Szenarien entworfen; schon ab ein paar Dutzend Entwicklern wird LeSS als „radikaler Ansatz“ schwerfällig . In sehr kleinen Unternehmen oder bei wenig Vernetzung spricht daher vieles dafür, mit simplen Abstimmungsmechanismen (z.B. Scrum of Scrums, Communities of Practice) zu arbeiten.

• Je ausgereifter die Teams, desto eher Rahmen: Unternehmen, die bereits eine gelebte agile Basis besitzen, profitieren mehr von Skalierungsframeworks. Wenn Teams selbstorganisiert, cross-funktional und technisch diszipliniert arbeiten, lassen sich übergeordnete Koordinations-Events und Rollen gut einführen. Fehlt dieser Reifegrad, stören neue Vorgaben oft mehr als sie nutzen. Experten raten, den aktuellen agilen Reifegrad zu erheben, bevor man skaliert . Nur so erkennt man, ob Teams wirklich bereit für übergreifende Synchronisierung sind oder ob zuerst fundamentale Kompetenzen gefördert werden müssen.

• Klare Zielsetzung: Manchmal genügt ein genereller Wunsch nach „mehr Agilität“. In solchen Fällen wirken Frameworks wie ein Selbstzweck und verfehlen ihre Wirkung. Skalierung macht nur dann Sinn, wenn konkrete Probleme gelöst werden sollen – z.B. wenn lange Release-Zyklen gekürzt oder Abhängigkeiten zwischen Teams transparent gemacht werden müssen. Wenn das vage Ziel stattdessen „Innovation steigern“ lautet, sollte zunächst hinterfragt werden, ob nicht andere Maßnahmen (Training, Strukturreformen, Prozessoptimierung) zielführender sind.

• Kultur und Führung: Ein agiles Framework hilft nur, wenn das Top-Management mitzieht. Studien zeigen: „Das Top-Management muss die Transformation aktiv unterstützen und die gemeinsame Vision und die Ziele der Veränderung klar kommunizieren“ . Wer als Entscheider nur auf Verordnungen und Kontrolle setzt, wird mit Skalierungsframeworks schnell in Konflikt geraten. Liegt im Unternehmen ohnehin die Führungskultur noch im Befehlsstil, kann ein weiteres Regelwerk eher Fronten verhärten, statt Gemeinsamkeit zu schaffen.

Kurz gesagt: Wer keinen großen Koordinationsbedarf hat oder dessen Kultur (noch) nicht agil ist, sollte besser die Finger von einem schweren Framework lassen. Ein Framework zu verwenden, ohne die genannten Bedingungen zu erfüllen, produziert meist nur Ballast. In vielen Fällen sind pragmatische Zwischenlösungen weitaus effektiver.

Alternativen zur starren Skalierung

Wer erkennt, dass klassische Frameworks nicht passen oder zu viel Verwaltung erzeugen, hat mehrere Wege nach vorn:

• Prinzipienorientierter Ansatz: Statt einen Blueprint zu kopieren, sollte man agile Prinzipien ins Zentrum stellen. Wie it-agile betont: „Agile Skalierung bedeutet, eine lernende Organisation zu gestalten. Dabei hilft es nicht, einen Blueprint für Skalierung … zu kopieren. Stattdessen müssen die agilen Prinzipien konsequent angewendet werden, um den eigenen Weg zu finden.“ . In der Praxis heißt das, dem „Wir machen jetzt SAFe“-Reflex zu widerstehen und lieber Schlüsselfragen zu klären: Bin ich klar bei Wertstrom, Kunden-Feedback und Selbstorganisation? Verstehe ich den eigentlichen Geschäftsprozess? So kann eine Organisation etwa nach und nach agile Praktiken ausweiten – ohne ein festes Framework zu fahren.

• Kultureller Wandel statt Rollenhandbuch: Agilität ist vor allem ein Mindset. „Agil bedeutet Kulturwandel,“ mahnen Agile-Coaches . Die Zusammenarbeit muss auf Offenheit, Vertrauen und Kundenorientierung ausgerichtet werden. Das erreicht man nicht durch zusätzliche Managementebenen, sondern etwa durch agile Führungstrainings, Veränderung der Anreizsysteme oder Förderung psychologischer Sicherheit. Ein Beispiel: Anstatt formelle Planungsmeetings auf allen Ebenen einzuführen, kann man Führungskräfte befähigen, ihren Teams mehr Autonomie zu geben und über mögliche Hindernisse nur als Servants tätig zu sein.

• Team-of-Teams-Koordinierung: Ein weiterer Ansatz kommt von General Stanley McChrystal: Er schlägt vor, Teams nicht über neue Ebenen zu vernetzen, sondern durch ein Netzwerk aus „Teams von Teams“. Dabei halten alle Teams tägliche Absprachen (Cross-Team-Stand-ups) und bilden flexible Konstellationen, die sich am Wertstrom orientieren. It-agile etwa erklärt, dass auch viele Teams zusammen schnell vorankommen können, wenn sie „radikalen Wertschöpfungsfokus“ haben und diesen Mut zur Veränderung mitbringen . In solchen Modellen gibt es keine neue Befehlskette – stattdessen wird viel Energie darauf verwendet, Hindernisse gemeinsam aus dem Weg zu räumen und Wissen zu teilen.

• Spotify-Modell und Autonomie-Netzwerke: Viele Firmen orientieren sich am berühmten Spotify-Modell: Hier stehen selbstorganisierte Squads im Mittelpunkt, die in lockeren Tribes vernetzt sind. Wichtiger als fixe Regeln sind Kultur und Kommunikation . So lauten auch die Erkenntnisse von Henrik Kniberg: Der Begriff „Spotify-Modell“ ist eher ein Mindset-Ansatz als ein starres Gerüst. Er betont, dass echte Agilität durch Freiheit und Eigenverantwortung entsteht, nicht durch ein zusätzliches Management-Korsett .

Diese und ähnliche Ansätze zeigen: Es gibt Wege, Agilität großflächig zu fördern, ohne gleich ein schwergewichtiges Framework aufzufahren. Oft kann schon ein gut begleitetes Experiment in einem Bereich ausreichen, um zu lernen, wie Skalierung organisch funktionieren kann – zum Beispiel durch schrittweises Anwenden agiler Prinzipien oder dem Einsatz von Tools wie OKRs oder Kanban im Maßstab.

Was Entscheider wissen und kritisch hinterfragen sollten

Als Entscheider:in bist du Dreh- und Angelpunkt der Transformation. Folgende Punkte solltest du genau prüfen:

• Zielklarheit: Frage dich: Welches konkrete Problem soll Agilität lösen? Geht es um Geschwindigkeit, Innovation, bessere Qualität oder Kostensenkung? Ohne klare Zielsetzung besteht die Gefahr, dass Agilität Selbstzweck wird. Ein Framework allein löst keine Motivation, und wer nichts zu lösen hat, zementiert nur Prozesse.

• Agiler Reifegrad: Lass prüfen, wie agil dein Unternehmen schon ist. Der aktuelle Reifegrad gibt Hinweise, ob die Voraussetzungen für Skalierung gegeben sind . Wenn Teams kaum Erfahrung mit selbstorganisiertem Arbeiten haben, und Führung noch sehr hierarchisch ist, sollte zuerst an diesen Baustellen gearbeitet werden. Den eigenen Status zu diagnostizieren – etwa in Form eines Workshops oder Audits – verhindert später böse Überraschungen.

• Führungskompetenz: Höre nicht nur auf Verkäufer:innen, sondern nimm Führungskräfte mit ins Boot. Studies belegen: „Das Top-Management muss die Transformation aktiv unterstützen und Vision und Ziele der Veränderung klar kommunizieren“ . Prüfe: Verstehen deine Führungskräfte die Bedeutung agiler Werte? Sind sie bereit, Verantwortung abzugeben? Wir haben oft erlebt, dass Change-Vorhaben floppen, wenn der Vorstand zwar nach außen ein Framework wählt, aber hinter den Kulissen weiterhin klassisch steuert. Bildung und Coaching der Führungsebene sind deshalb unerlässlich.

• Eigenes Beratungsteam: Betrachte das Vorhaben nicht isoliert. Nutze externe Expertise, um eure Blinde Flecken aufzudecken. Ein klassischer Fehler ist, Skalierung ohne objektive Diagnose „on the fly“ anzugehen. Wir empfehlen deshalb, zunächst einen Diagnose-Workshop zum agilen Reifegrad und zur Organisationsstruktur durchzuführen. Dort kann ermittelt werden, ob überhaupt erst einmal Grundlagen geschaffen werden müssen. Ergänzend kann ein Transformations-Sparring helfen: In regelmäßigen Meetings (etwa monatlich) beraten wir gemeinsam mit euch über Fortschritte, lösen Konflikte und justieren die Strategie. So bleibt die Einführung nicht beim reinen Durchsteppen eines Frameworks stecken, sondern wird fortwährend an eure Situation angepasst.

• Kosten-Nutzen-Bilanz: Skalierungsframeworks sind – das zeigen Erfahrungen – mit erheblichem Ressourcenaufwand verbunden. Neben Lizenzgebühren (z.B. für SAFe-Zertifikate) kommen vor allem Personalkosten für Ausbildung, zusätzliches Coaching, mehr Meetings etc. Gegengerechnet muss stehen, ob die erwarteten Vorteile wirklich in gleichem Umfang erzielt werden. Kalkuliere also genau: Helfen dir sieben agile Release Trains tatsächlich weiter, oder genügt vielleicht ein pragmatischer Planungsprozess im Bereich Produktentwicklung?

Wenn du diese Punkte ehrlich prüfst, vermeidest du, dass ein Framework deine Organisation überrollt, statt sie zu stärken. Denn nur du kennst die individuellen Stärken und Schwächen deines Unternehmens. Fehlt es zum Beispiel an Transparenz über Prozessschritte oder an End-to-End-Verantwortung, könnte eine schlanke Abstimmungsstruktur (Team-of-Teams) besser helfen als ein träges Rollengerüst.

Als externe Berater haben wir beobachtet, dass gezielte Workshops und Transformationsteams gerade für Entscheider:innen sehr wertvoll sind. So führen wir beispielsweise Agile-Reifegrad-Checks durch oder moderieren Strategie-Workshops, bei denen wir gemeinsam die Passung eines Frameworks evaluieren. Auch ein frühzeitiges Transformations-Sparring (kontinuierliches Coaching) kann viele Stolpersteine aus dem Weg räumen, bevor sie zum echten Problem werden. Auf diese Weise bleibt Agilität anpassbar und wird nicht zum Dogma.

Dein nächster Schritt

Es gibt also keinen Patentweg: SAFe, LeSS, Nexus – oder ganz auf eigene Faust. Welcher Pfad der richtige ist, hängt stets vom Ziel, der Kultur und dem Reifegrad ab. Wenn du als Entscheider:in nach dieser Analyse noch unsicher bist, welcher Ansatz für dein Unternehmen passt, lass uns reden:

Wir bieten genau die Unterstützung, die du jetzt brauchst, um Klarheit zu gewinnen – von der agilen Organisationsdiagnose über Workshops bis hin zum begleiteten Sparring. In einem Erstgespräch oder einem kurzen Assessment gemeinsam können wir den Status quo abstecken und abwägen, ob und in welcher Form ein Framework zu eurer Situation beiträgt. So findest du heraus, ob skalierende Methoden euch wirklich voranbringen oder ob andere Ansätze effektiver sind.

Kontaktiere uns einfach unverbindlich – gemeinsam entwickeln wir einen Fahrplan, der deine Organisation statt in neues Chaos in eine echte agile Zukunft führt. Wir freuen uns darauf, dich und dein Team auf dem Weg zu echtem (nicht nur scheinbarem) Erfolg zu begleiten.

Quellen:

• Agile Alliance (2023): Introduction to Scaling Agile.

  https://www.agilealliance.org/introduction-to-scaling-agile

• AgilityHealth (2023): Enterprise Business Agility Model.

  https://www.agilityhealthradar.com/enterprise-business-agility-model

• Gothelf, Jeff (2019): Why SAFe isn’t Agile.

  https://jeffgothelf.com/blog/why-safe-isnt-agile

• it-agile (2023): Skalierung agiler Organisationen – Blueprint oder Prinzipien?

  https://www.it-agile.de/wissen/skalierung-agiler-organisationen/

• Kniberg, Henrik (2015): Spotify Engineering Culture (Part 1 & 2).

  https://blog.crisp.se/2014/03/27/henrikkniberg/spotify-engineering-culture-part-1

• McChrystal Group (2021): Team of Teams – How to Adapt to Complexity.

  https://www.mcchrystalgroup.com/library/team-of-teams/

• McKinsey & Company (2022): Agile transformation: Practical imperatives.

  https://www.mckinsey.com/business-functions/organization/our-insights

• Project Management Institute (PMI) (2022): Pulse of the Profession – PM Trends Report.

  https://www.pmi.org/learning/thought-leadership/pulse

• Scaled Agile Inc. (2024): The SAFe Framework.

  https://www.scaledagileframework.com

• Scrum.org (2023): The Nexus Guide – The Definitive Guide to Scaling Scrum.

  https://www.scrum.org/resources/nexus-guide

• Scrum Alliance (2023): What is LeSS?

  https://less.works/less

• Statista (2023): Wachstumszahlen agiler Unternehmen weltweit.

  https://www.statista.com/statistics/1292631/agile-organizations-revenue-growth