Die grossen Beratungs-Agile-Frameworks im Vergleich: SAFe, LeSS, Scrum@Scale, Spotify, DAD, Nexus, KMM, FAST — und wie BCG, McKinsey, Deloitte, EY, PwC, KPMG, Accenture, Bain, Capgemini und IBM sie verpacken (Ausgabe 2026)
Ein Praktiker-Referenzwerk: was die acht Scaled-Agile-Frameworks tatsächlich vorschreiben, was die zehn grossen Beratungen obendrauf packen, und wie ein Käufer den Unterschied lesen sollte — mit Primärquellen und benannten Flagship-Fällen durchgehend.
Warum überhaupt vergleichen?
„SAFe versus LeSS" wird eine Million Mal gegoogelt. „Spotify-Modell Alternativen" nochmals eine halbe Million Mal. Hinter diesen Suchanfragen steckt fast nie ein Transformation Officer, der vergleichende Literaturarbeit betreibt. Es ist ein CEO, ein CIO oder ein Aufsichtsratsmitglied, das vor dem Meeting nächste Woche herausfinden will, was der Beratungspartner am Montagmorgen tatsächlich tun wird — und ob die Agile-Ausprägung im Angebot echte Methode, echtes Engineering oder nur ein Relabeling derselben Spotify-Tribe-Folie ist, die schon die letzten drei Pitches gewonnen hat.
Die ehrliche Antwort ist schwerer zu finden, als sie sein sollte. Die meisten öffentlichen Framework-Vergleiche werden von den Methodenanbietern selbst geschrieben — Scaled Agile Inc. über SAFe, die LeSS Company über LeSS, Scrum Inc. über Scrum@Scale — und jeder gewinnt das Argument, das er selbst geschrieben hat. Die Beratungen publizieren Thought Leadership über ihre eigenen Angebote, ohne offenzulegen, welche Basismethode sie darüberlegen, welche sie stillschweigend meiden oder welche ein Engagement produziert hat, das seither zurückgerollt wurde. Der Käufer bleibt zurück, um zu triangulieren — meist unter Zeitdruck — zwischen einer Methodenseite, die Zertifizierungsumsatz will, und einer Firmenseite, die einen Vertrag will.
Dieser Beitrag ist ein Praktiker-Referenzwerk aus der Käuferperspektive. Die Rahmung ist diese: Es gibt 2026 acht Scaled-Agile-Frameworks, die man kennen sollte, und zehn Beratungen, die Agile-Transformationen im grossen Stil verkaufen. Jedes Framework ist ein echtes Produkt mit einem echten Autor, einer echten Skalierungstheorie und einer echten Meinung zur Engineering-Praxis. Jede Firma umhüllt eines oder mehrere dieser Frameworks mit gebrandeter IP, einem Zertifizierungsstack und einem Flagship-Fall. Die interessanten Fragen sind jene, die Firmen und Methodenanbieter am wenigsten selbst beantworten: wo die Hülle echte Methode hinzufügt, wo sie nur Marke hinzufügt, wo der benannte Flagship-Fall fünf Jahre später noch genauso aussieht, und wo die Engineering-Annahmen des Frameworks noch halten, wenn man Teamgrössen im KI-Zeitalter berücksichtigt.
Wir haben eine Präferenz, und wir sagen sie gleich zu Beginn, um den Rest des Beitrags ehrlich zu halten. Agile ist nicht das Produkt. Agile ist die Delivery-Schicht unter jedem KI-, Digital- und Operations-Programm, das nach der Launch-Zeremonie weiter liefern muss. Das Framework, das das für eine gegebene Organisation am besten leistet, ist selten jenes mit dem grössten Zertifizierungs-Ökosystem oder der lautesten Marke. Es ist meist jenes, dessen Engineering-Annahmen, Governance-Form und Team-Grössen-Sweet-Spot zur Arbeit passen, die dem Käufer dieses Quartal vorliegt. Es falsch zu wählen, ist der teuerste Fehler in Transformationsbudgets — und derjenige, der im Post-Mortem der „Kultur" zugeschrieben wird.
Was folgt, ist so aufgebaut, dass ein CEO es in fünfzehn Minuten lesen und ein Transformation Officer es als Arbeitsreferenz nutzen kann. Abschnitt 3 setzt die acht Frameworks in die Zeitlinie, die sie hervorgebracht hat, denn ohne die Geschichte ergibt nichts von dieser Arbeit einen Sinn. Die Abschnitte 4 und 5 vergleichen die Frameworks und die Firmen Seite an Seite. Abschnitt 6 ist die Tabelle, die man screenshotten kann. Die Abschnitte 7 und 8 sagen, was anders ist und was Dekoration ist. Abschnitt 10 gibt Ihnen den Entscheidungsbaum aus Käuferperspektive. Abschnitt 11 sagt, wo wir passen.
Eine Anmerkung zur Methode
Das Snapshot-Datum für diesen Vergleich ist der 14. Mai 2026. Framework-Guides, Firmen-Capability-Seiten und Fallstudien-Bibliotheken ändern sich; alles unten spiegelt den öffentlichen Stand an diesem Datum. Spätere Ausgaben werden die vorherige Ausgabe unter einer datierten URL bewahren, damit jeder, der diesen Beitrag zitiert, die referenzierte Version fixieren kann.
Primärquellen für die acht Frameworks. Wo ein Framework ein kanonisches Buch hat, ist das Buch die Primärquelle. SAFe: Dean Leffingwell, SAFe Reference Guide (Scaled Agile Inc., aktuelle Ausgabe für SAFe 6.0). LeSS: Craig Larman und Bas Vodde, Large-Scale Scrum: More with LeSS (Addison-Wesley, 2017), plus ihr früheres Practices for Scaling Lean & Agile Development (2008). Scrum@Scale: Jeff Sutherland, The Scrum@Scale Guide plus Scrum: The Art of Doing Twice the Work in Half the Time (Sutherland und Sutherland, 2014). Spotify-Modell: Henrik Kniberg und Anders Ivarsson, „Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds" (2012), plus die Spotify-Engineering-Culture-Videos (Kniberg, 2014) und die späteren Retrospektiven von Joakim Sundén und Marcin Floryan. Disciplined Agile: Scott Ambler und Mark Lines, Choose Your WoW! (PMI, aktuelle Ausgabe). Nexus: Ken Schwaber und Scrum.org, The Nexus Guide. Kanban Maturity Model: David J. Anderson und Teodora Bozheva, Kanban Maturity Model (Lean Kanban Inc., 2018). FAST: Ron Quartel, The FAST Guide, plus Community-Talks.
Primärquellen für die zehn Firmen. Jede Firma ist aus ihren eigenen publizierten Capability-Seiten, White Papers und Pressemitteilungen zum Snapshot-Datum belegt, plus — wo vorhanden — öffentlich benannten Flagship-Fallstudien. Wo eine Firma ein SAFe Global Transformation Partner ist, wird das öffentliche Partnerverzeichnis als unabhängig bestätigende Quelle behandelt. Branchenweite Adoptionsdaten stammen aus dem jährlichen State of Agile-Report (digital.ai) und Scrum.org-Community-Statistiken. Wir vermeiden interne Firmen-Interviews als Quelle; alles unten hat eine öffentliche Quelle.
Was im Scope ist und was nicht. Drin: Frameworks mit benanntem Autor, publizierter Methodik und aktiver Praktiker-Community auf Team-of-Teams-Ebene oder höher. Drin: Firmen, die ein gebrandetes Agile-Transformationsangebot publizieren und eine nennenswerte zertifizierte oder spezialisierte Consultant-Bank haben. Draussen: reine Team-Ebenen-Frameworks (Scrum, Extreme Programming, Single-Team-Kanban — das sind Bausteine der Scaled-Frameworks, keine Konkurrenten dazu). Draussen: Agile-Coaching-Zertifizierungen ohne darunterliegende Delivery-Methodik. Draussen: Boutique-Beratungen unter fünfzig Consultants — die Käuferfrage, der dieser Beitrag dient, betrifft Firmen, die ein Enterprise-Programm mobilisieren können.
Warum acht Frameworks, nicht sechs oder zwölf. Sechs würde das Feld untertreiben: Liesse man Kanban Maturity Model und FAST weg, verschwänden die beiden Frameworks, die explizit keine Team-Struktur-Reorganisation erfordern — genau die Situation, vor der viele Post-Merger- oder politisch eingeschränkte Organisationen stehen. Zwölf würde es übertreiben: Die meisten zusätzlichen Frameworks (Nexus+, Disciplined Agile Enterprise, einzelne Firmen-Wrapper) sind Erweiterungen oder Rebrandings der acht hier. Die acht in diesem Beitrag haben entweder einen benannten Autor mit publizierter Methode und aktiver Community, oder sie sind das einzige gebrandete Asset, das eine grosse Firma unter eigenem Namen publiziert.
Eine kurze Geschichte von Scaled Agile (2001-2026)
Keines der Frameworks in diesem Vergleich ergibt ohne die Geschichte Sinn. Scaled Agile ist ein fünfundzwanzigjähriges Argument darüber, wie man Software in einer Grösse und einem Tempo liefert, das die ursprünglichen Autoren des Agile Manifesto nie zu bewältigen versuchten, und fast jede Meinungsverschiedenheit in der aktuellen Literatur lässt sich darauf zurückführen, welches Jahr, welches Problem und welche Engineering-Kultur das Framework hervorgebracht hat, das dafür argumentiert.
2001 — Agile Manifesto. Siebzehn Praktiker treffen sich in Snowbird, Utah, und publizieren vier Werte und zwölf Prinzipien. Jedes Framework in diesem Beitrag ist in irgendeiner Form ein Nachkomme. Entscheidend: Das Manifest schweigt zur Koordination über mehr als ein Team hinweg. Diese Lücke füllt der Rest dieser Geschichte.
1994-1999 — die Vorgeschichte. DSDM (Dynamic Systems Development Method) wird 1994 in Grossbritannien publiziert, mit einer expliziten Skalierungsgeschichte für Fixed-Budget-Delivery. FDD (Feature-Driven Development) erscheint 1997 aus Jeff De Lucas Arbeit in Singapur. RUP (Rational Unified Process) wird 1998 bei Rational Software finalisiert und 2003 von IBM übernommen, was grossen Unternehmen einen käuflichen, schwergewichtigen iterativen Prozess gibt. Keines davon ist „agil" nach der Definition von 2001, aber sie beweisen, dass dasselbe Problem — koordinierte Multi-Team-, Multi-Phasen-Delivery — bereits gelöst wurde, bevor das Manifest das Wertesystem benannte.
2007-2010 — Scrum skaliert aus Versehen. Scrum (Schwaber und Sutherland, in den 1990ern formalisiert, nach dem Manifest popularisiert) wird zur dominanten Team-Ebenen-Methode. Grössere Organisationen übernehmen es, stossen an die Grenze eines einzelnen Scrum-Teams und beginnen, lokale Lösungen zu erfinden. Das „Scrum of Scrums"-Muster wird dokumentiert, aber nicht governt. Die ersten publizierten Versuche gezielter Skalierung erscheinen in dieser Periode — Craig Larmans und Bas Voddes Practices for Scaling Lean & Agile Development (2008) ist die früheste ernsthafte Behandlung in Buchform.
2011 — SAFe 1.0. Dean Leffingwell publiziert das erste Scaled Agile Framework. Es ist das erste Scaled-Agile-Framework, das wie ein käufliches Produkt aussieht: nummerierte Rollen, benannte Zeremonien (allen voran PI Planning), eine Portfolio-Schicht über der Programm-Schicht und ein Zertifizierungsstack. Enterprise-Transformation-Officer, die sich bisher schwertaten, Team-Ebenen-Scrum auf Programm-Ebenen-Governance abzubilden, haben endlich etwas, das sie auf eine Folie packen können. Scaled Agile Inc. wird im selben Jahr gegründet. Von diesem Punkt an definiert sich jedes andere Framework im Feld zum Teil darüber, wo es SAFe zustimmt oder widerspricht.
2012-2014 — Spotify und LeSS. Henrik Kniberg und Anders Ivarsson publizieren 2012 „Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds". Es ist ein Whitepaper, kein Framework. Das Vokabular — Tribes, Squads, Chapters, Guilds — verbreitet sich schneller als jedes Framework davor oder danach. 2014 veröffentlicht Kniberg die Spotify-Engineering-Culture-Videos. Im selben Jahr lancieren Larman und Vodde das LeSS-Framework öffentlich auf less.works und positionieren es explizit als „Scrum mit den Regeln, die man braucht, um es zu skalieren" — eine bewusste Gegenposition zur Rollen- und Zeremoniendichte von SAFe.
2014-2015 — Scrum@Scale und Disciplined Agile. Jeff Sutherland publiziert Scrum@Scale, behält den originalen Scrum-Minimalismus im Kern und fügt zwei Koordinationszyklen hinzu (Scrum-Master-Zyklus und Product-Owner-Zyklus). Scott Ambler und Mark Lines, ursprünglich bei IBM, publizieren Disciplined Agile Delivery als Toolkit-Alternative, die planbasierte, agile und schlanke Lifecycles im selben Programm unterstützt — eine bewusste Zugeständnis an Unternehmen, die keine einzelne Delivery-Philosophie übernehmen können.
2015-2016 — Nexus. Ken Schwaber und Scrum.org lancieren Nexus als die Option „Scrum, nur ein bisschen grösser": ein Exoskelett für drei bis neun Scrum-Teams, die sich ein Produkt teilen, mit einem Nexus Integration Team, das die teamübergreifende Integration verantwortet. Geringere Markenoberfläche als SAFe oder LeSS, aber sauberer für Teams, die bereits im Scrum.org-Ökosystem verankert sind.
2018 — Kanban Maturity Model und die Five Trademarks. David J. Anderson und Teodora Bozheva publizieren das Kanban Maturity Model und formalisieren einen nach Reifegraden gestuften Praxiskatalog, der keine Team-Struktur-Änderungen erfordert — das erste Framework, das explizit für Organisationen konzipiert ist, die nicht reorganisieren können oder wollen. Im selben Jahr publiziert McKinsey „The five trademarks of agile organizations" (Bazigos, De Smet, Gagnon) und gibt Beratungen damit ein Nicht-Framework-Diagnostikum, das sie in Aufsichtsratssitzungen verkaufen können.
2017-2019 — FAST und PMIs DAD-Akquisition. Ron Quartel publiziert 2017 das FAST-Framework — das radikalste flexible der Gruppe, mit dynamischer Teambildung und ohne Scrum Master. 2019 akquiriert PMI Disciplined Agile, was dem Framework Enterprise-Glaubwürdigkeit gibt und seine Open-Community-Geschwindigkeit in ungefähr gleichem Mass verlangsamt.
2019-2022 — SAFe-Konsolidierung, Spotify-Retrospektiven. SAFe gewinnt das Argument in regulierten Branchen quasi standardmässig: Es ist das einzige Framework mit audit-freundlichen, benannten Rollen, Zertifizierung und einem Scaled-Agile-Inc.-Partner-Ökosystem, das einem Käufer erlaubt, Spezial-Consultants auf Abruf zu bekommen. Parallel dazu publizieren Joakim Sundén und andere aus der ursprünglichen Spotify-Ära Retrospektiven, die klarstellen, dass das „Spotify-Modell" immer eine Momentaufnahme war, nie ein Modell — und dass Spotify selbst sich längst über diese Diagramme hinausentwickelt hat.
2023-2026 — Druck im KI-Zeitalter. Generative KI komprimiert die Teamgrösse. Arbeitspakete, die 2018 einen Tribe von achtzig Personen brauchten, lassen sich mit acht bis fünfzehn Personen liefern, unterstützt durch Platform Engineering und KI-gestützte Entwicklung. Platform Engineering ersetzt manche Koordinationszeremonien durch interne Developer-Plattformen. Die Frameworks unter strukturellem Druck sind jene, die für Headcount-lastige Programme gebaut wurden; die Frameworks, die still an Boden gewinnen, sind jene, die sauber herunterskalieren (FAST, KMM, LeSS) oder eine Headcount-Kürzung überleben, ohne ihre Identität zu verlieren.
Das ist der Kanon. Die acht im nächsten Abschnitt verglichenen Frameworks sind die acht, die dieses fünfundzwanzigjährige Argument mit einer publizierten Methode, einem benannten Autor und einer aktiven Community 2026 überlebt haben. Alles andere ist entweder eine Team-Ebenen-Methode (ausserhalb des Scopes), ein Anbieter-Wrapper eines dieser acht (Abschnitt 5) oder eine Idee, die den Kontakt mit Enterprise-Budgets nicht überlebt hat.
Acht Frameworks, acht Framings
Jede Methode ist ihr eigenes Produkt, mit eigenem Autor, eigenen Skalierungsannahmen und einer eigenen Theorie darüber, wo Software-Engineering-Praxis hineinpasst. Die Reihenfolge unten orientiert sich grob am Adoptionsgewicht in Enterprise-Beratungsengagements, nicht an Qualität.
Vor den Framings die Herkunft — denn die meiste scheinbare Vielfalt kollabiert, sobald man sieht, woher jede Methode kommt. Fünf der acht sind Erweiterungen von Scrum, eine stammt von der Kanban-Methode ab, und zwei haben unabhängige Wurzeln. Diese Abstammung ist das mit Abstand Nützlichste, was man beim Lesen dieses Abschnitts im Kopf behalten sollte: Wenn ein Framework unvertraut wirkt, erklärt die Frage „was skaliert es, und aus welcher Tradition?" meist seine Form.
1. SAFe — Scaled Agile Framework
Autor / Herkunft: Dean Leffingwell, erste öffentliche Version 2011, SAFe 6.0 aktuell seit 2023. Im Besitz und markenrechtlich geschützt von Scaled Agile Inc.
Skalierungsannahme: Aufgebaut um den Agile Release Train (ART) von 50-125 Personen. Die Konfigurationen Large Solution und Portfolio erweitern die Koordination auf Multi-ART-Programme von mehreren Tausend. Top-down für Unternehmen konzipiert, nicht bottom-up aus Team-Ebenen-Scrum.
Präskriptiv vs. flexibel: Das präskriptivste Framework in diesem Vergleich. Benannte Rollen (RTE, Product Manager, Solution Train Engineer, System Architect, Business Owner, Release Train Engineer, plus Team-Ebenen-Scrum-Master und Product Owner). Benannte Kadenzen (der PI — Program Increment — meist 8-12 Wochen). Benannte Zeremonien (PI Planning, System Demo, Inspect & Adapt). Benannte Artefakte (Programme Backlog, Solution Backlog, Portfolio Kanban).
Governance-Form: Hierarchisch — Portfolio → Large Solution → Essential (ART) → Team. Portfolio-Lean-Budgeting-Schicht mit Strategic Themes und Value Streams. Audit-freundlich: Jede Rolle, Zeremonie und Entscheidung ist rückverfolgbar.
Software-Engineering-Tiefe: DevOps und die Continuous Delivery Pipeline sind benannte Top-Level-Säulen. Built-In Quality, Test-First und die zugrundeliegenden XP-Praktiken werden explizit referenziert. In der Praxis hängt die Engineering-Tiefe fast ausschliesslich vom SPC (SAFe Programme Consultant) ab, der die Implementierung leitet; die Zeremonien-Adoption überholt typischerweise die Engineering-Adoption.
Wo es glänzt: Regulierte Branchen (Banken, Pharma, Verteidigung), die auditrückverfolgbare Governance brauchen. Grosse Unternehmen mit reifen Programme Management Offices, die bereits in Rollen und Zeremonien denken. Multi-Vendor-Delivery-Kontexte, in denen gemeinsame Kadenz und benannte Koordinationsrollen das Integrationsrisiko senken.
Wo es falsch angewendet wird: Kleine Organisationen, die das volle Framework übernehmen, weil der Zertifizierungspfad es sichtbar gemacht hat. PI-Planning-Theater — die zweitägige Zeremonie als Ritual übernommen, ohne die zugrundeliegende Engineering-Praxis, die die nächsten zwölf Wochen lieferbar macht. Portfolio Kanban als Budget-Rechtfertigungsartefakt statt als Flow-Tool. Jedes Deployment, bei dem der SPC nie Produktionscode geschrieben hat.
Einschätzung: Das Framework, das skalierte, weil es die Enterprise-Prüfung überlebte. Von Transformation Officers geliebt, weil jedes Gespräch, das sie mit einem Aufsichtsrat führen müssen, ein benanntes SAFe-Artefakt im Hintergrund hat. Von Senior Engineers argwöhnisch beäugt, weil dasselbe Gespräch selten an eine CI-Pipeline anschliesst. Die häufigste Lücke zwischen dem SAFe-Diagramm an der Wand und der Engineering-Praxis in der IDE.
Quellen: Leffingwell, SAFe Reference Guide (Scaled Agile Inc.) · scaledagileframework.com · Scaled Agile Inc. Partnerverzeichnis · State of Agile Report (digital.ai, jährlich)
2. LeSS — Large-Scale Scrum
Autor / Herkunft: Craig Larman und Bas Vodde, entwickelt aus ihrer Arbeit bei Nokia Siemens Networks Mitte der 2000er. Erstes Buch Practices for Scaling Lean & Agile Development (2008); das LeSS-Framework 2014 auf less.works formalisiert; Large-Scale Scrum: More with LeSS (2017) ist der kanonische Text.
Skalierungsannahme: Ein Produkt, ein Product Owner, ein Product Backlog. LeSS im engeren Sinn deckt 2-8 Teams ab. LeSS Huge deckt 8+ Teams ab, organisiert in Requirement Areas mit je einem Area Product Owner. Die Ein-Produkt-Annahme ist das zentrale Bekenntnis des Frameworks und seine am schwersten zu erfüllende Bedingung.
Präskriptiv vs. flexibel: Minimalistisch per Design. Das Motto lautet „Scrum angewendet auf viele Teams, die gemeinsam an einem Produkt arbeiten", mit nur den zusätzlichen Regeln, die dafür nötig sind — keine parallele Programmschicht. Weniger benannte Rollen, weniger benannte Events, kein Portfolio-Overlay.
Governance-Form: Bewusst flach. Ein Product Owner über alle Teams hinweg (oder ein Area PO pro Requirement Area in LeSS Huge). Keine separate Programmschicht. Kein Äquivalent zum Release Train Engineer. Teamübergreifende Koordination geschieht über Multi-Team PBR, Overall Retrospective und Component-Mentor-/Travelling-Engineer-Muster, nicht über eine hierarchische Rolle.
Software-Engineering-Tiefe: Unter den höchsten der acht. Continuous Integration ist nicht verhandelbar. Das Framework verlangt explizit technische Exzellenz: Refactoring, einfaches Design, testgetriebene Entwicklung und geteilte Code-Ownership gelten als Vorbedingungen, nicht als Wunschziele. Larman und Vodde haben ausführlich über die Engineering-Praktiken geschrieben, die LeSS voraussetzt.
Wo es glänzt: Single-Produkt-Organisationen mit Engineering-Kulturen, die schon zur Hierarchieabflachung neigen. Software-Produktfirmen, Plattform-Teams innerhalb grösserer Unternehmen, Organisationen, die bereit sind, Komponententeam- und Funktions-Silos zugunsten von Feature-Teams aufzulösen.
Wo es falsch angewendet wird: Multi-Produkt-Portfolios, die versuchen, die Ein-PO-Annahme zu erzwingen. Regulierte Branchen, in denen das Audit benannte Compliance-Rollen erwartet, die LeSS nicht liefert. Organisationen, die die Struktur übernehmen, aber die Engineering-Vorbedingungen überspringen — LeSS ohne Continuous Integration ist nur Scrum mit zusätzlichen Retros.
Einschätzung: Das Framework, das Ingenieure respektieren. Das Framework, das Transformation Officers am schwersten an einen Aufsichtsrat verkaufen können, weil es weniger markenerkennbare Artefakte bietet als SAFe. Jenes mit den besten Ergebnissen in den Händen eines starken technischen Führungsteams, und den schlechtesten, wenn es einer Organisation aufgezwungen wird, die sich die vorausgesetzte Engineering-Disziplin noch nicht erarbeitet hat.
Quellen: Larman und Vodde, Large-Scale Scrum: More with LeSS (Addison-Wesley, 2017) · less.works · LeSS-Company-Zertifizierung (CLP, CLT) · Larman und Vodde, Practices for Scaling Lean & Agile Development (2008)
3. Scrum@Scale
Autor / Herkunft: Jeff Sutherland (Miterfinder von Scrum mit Ken Schwaber), Gründer von Scrum Inc. 2014 publiziert, aktuell Scrum@Scale Guide Version 3.0 (2022). Baut auf dem zugrundeliegenden Scrum Guide auf, den Sutherland und Schwaber gemeinsam verfassen.
Skalierungsannahme: Modular und rekursiv. Fünf Teams bilden ein Scrum of Scrums (SoS); fünf SoS bilden ein Scrum of Scrums of Scrums; und so weiter. Keine harte Team-Zahl-Grenze. Der Executive MetaScrum sitzt an der Spitze als strategisches Priorisierungsgremium. Das Framework ist so gebaut, dass es skaliert, indem dasselbe Muster auf höheren Ebenen wiederholt wird, statt auf jeder Ebene neue Schichten mit neuen Rollen einzuführen.
Präskriptiv vs. flexibel: Minimaler Kern, modularer Zuwachs. Die einzigen erforderlichen Rollen sind die Standard-Scrum-Rollen (Scrum Master, Product Owner, Developer). Alle zusätzlichen Komponenten — das SoS, das SoSoS, das Executive Action Team, der Executive MetaScrum — werden nur hinzugefügt, wenn die Organisation sie braucht. Näher an einem Meta-Framework als an einer einzelnen vorgeschriebenen Implementierung.
Governance-Form: Zwei parallele Zyklen. Der Scrum-Master-Zyklus behandelt das „Wie" — Impediment-Beseitigung, kontinuierliche Verbesserung, teamübergreifende Koordination. Der Product-Owner-Zyklus behandelt das „Was" — Backlog-Priorisierung, strategische Vision, Kundenfeedback. Jeder Zyklus hat seine eigene Meeting-Kadenz und seinen eigenen Verantwortlichen.
Software-Engineering-Tiefe: Wenig explizite Anleitung im Framework selbst. Sutherlands Bücher und das Scrum-Inc.-Training tragen starke Engineering-Praxis-Inhalte, aber der Framework-Guide schreibt keine spezifischen Praktiken vor. In der Praxis bedeutet das: Die Engineering-Tiefe hängt vom Scrum-Inc.-zertifizierten Trainer oder Consultant ab, der die Implementierung leitet.
Wo es glänzt: Organisationen, die Scrum auf Team-Ebene bereits effektiv betreiben und Koordination auf Multi-Team-Ebene brauchen, ohne ein SAFe-schweres Overlay zu erben. Mid-Market-Technologiefirmen. Engineering-geführte Organisationen, die ihre bestehende Scrum-Kultur durch das Scale-up hindurch bewahren wollen.
Wo es falsch angewendet wird: Organisationen, die Minimalismus mit Unklarheit verwechseln und das Framework aufgeben, bevor sich die modularen Komponenten einspielen. Transformationsprogramme, die Präskription erwarten und die Optionalität von Scrum@Scale verunsichernd finden. Implementierungen, die das SoS-Muster ohne den entsprechenden Product-Owner-Zyklus übernehmen und so Koordinationsaufwand ohne strategische Ausrichtung produzieren.
Einschätzung: Sutherlands Name trägt enormes Gewicht. Das Framework hat eine kleinere offene Community als SAFe oder LeSS, aber eine hohe Konzentration Scrum-Inc.-geschulter Consultants im Feld. Das Framework, das am häufigsten zitiert wird, wenn eine Organisation sagt „wir wollen unser Team-Ebenen-Scrum skalieren, ohne es umzubenennen". Weniger Markenoberfläche als SAFe; sauberere konzeptionelle Struktur als LeSS Huge.
Quellen: scrumatscale.com · The Scrum@Scale Guide v3.0 (Scrum Inc., 2022) · Sutherland und Sutherland, Scrum: The Art of Doing Twice the Work in Half the Time (Random House, 2014) · Scrum-Inc.-Zertifizierung (SSM, SPS)
4. Spotify-Modell
Autor / Herkunft: Henrik Kniberg und Anders Ivarsson, „Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds" (2012). Gefolgt von Knibergs Spotify-Engineering-Culture-Videos (Teil 1 und Teil 2, 2014). Nie von Spotify als offizielles Framework publiziert; die Originalpapiere beschreiben, was Spotify damals tat, mit expliziten Warnungen, dass sich das Modell weiterentwickeln würde. Spätere Retrospektiven (Joakim Sundén 2017, Marcin Floryan und andere) haben wiederholt klargestellt, dass Spotify selbst sich innerhalb ein bis zwei Jahren über diese Diagramme hinausbewegt hat.
Skalierungsannahme: Squads von typischerweise 6-12 Personen, funktionsübergreifend, autonom. Tribes gruppieren verwandte Squads, bei Spotify auf rund 100 Personen begrenzt, um ein Zugehörigkeitsgefühl zu bewahren. Chapters durchkreuzen Tribes nach Disziplin (Engineering, Design, Daten). Guilds sind freiwillige Interessengruppen, die die gesamte Organisation überspannen.
Präskriptiv vs. flexibel: Kulturell präskriptiv, strukturell suggestiv. Die kulturellen Vorgaben — Autonomie mit Alignment, Vertrauen statt Kontrolle, „lose gekoppelt, eng ausgerichtet" — sind konkret und anspruchsvoll. Die strukturellen Elemente (Tribes, Squads, Chapters, Guilds) beschreiben, was Spotify tat, sind aber nicht als Framework vorgeschrieben, das andere wortwörtlich übernehmen sollten.
Governance-Form: Matrix. Tribes verantworten Produktergebnisse und Roadmaps. Chapters verantworten Disziplinstandards und Personalführung für ihre Mitglieder. Guilds verantworten themenübergreifende Interessensgebiete. Entscheidend: Spotifys Governance setzte eine starke Produktmanagement-Funktion und eine starke Engineering-Plattform voraus — beides in den Diagrammen nicht explizit benannt, beides in der Praxis essenziell.
Software-Engineering-Tiefe: Impliziert, nicht spezifiziert. Das Modell setzt eine starke Engineering-Kultur voraus: Trunk-Based Development, Continuous Deployment, interne Plattformen und eine hohe Messlatte für Autonomie ohne architektonischen Drift. Adopter, die das Organigramm ohne die Engineering-Plattform kopieren, bekommen Koordinationschaos statt Autonomie.
Wo es glänzt: Technologie-native, produktgeführte Organisationen mit erheblichem bestehendem Investment in Platform Engineering und Developer Experience. Organisationen, die sich die vom Modell vorausgesetzte Engineering-Autonomie bereits erarbeitet haben. Oft ist der nützlichste Einsatz des Spotify-Modells ein Vokabular für Organisationen, die schon so funktionieren und Namen für das brauchen, was sie tun.
Wo es falsch angewendet wird: Der dominante Fehlschlagsmodus. Organisationen kopieren das Organigramm — Tribes, Squads, Chapters — ohne die Engineering-Kultur, die Produktmanagement-Funktion oder das Plattform-Investment, das die Struktur zum Funktionieren brachte. Sie bekommen das Diagramm, nicht die Ergebnisse. Spotifys eigene Retrospektiven sind eindeutig: Das Modell war eine Momentaufnahme, die Momentaufnahme ist veraltet, und sie als Zielarchitektur zu behandeln, ist ein Fehler.
Einschätzung: Das einflussreichste, am wenigsten umsetzbare Artefakt im Feld. Das Framework, das zitiert wird, wenn Leute meinen „wir wollen mehr wie Spotify sein" — was fast immer bedeutet, dass sie das Diagramm gelesen haben, aber nicht die Engineering-Beiträge. Nützlich als Vokabular, gefährlich als Vorlage. Das klarste Zeichen, dass eine Organisation über das Diagramm hinausgelesen hat: Sie verweist auf die Retrospektiven nach 2017, nicht nur auf das Papier von 2012.
Quellen: Kniberg und Ivarsson, „Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds" (2012) · Kniberg, „Spotify Engineering Culture" (Spotify Labs, 2014) · Sundén, „There is no Spotify Model" (2017) · Floryan und andere, spätere Spotify-Retrospektiven
5. Disciplined Agile (DA / DAD)
Autor / Herkunft: Scott Ambler und Mark Lines, ursprünglich ab etwa 2009 bei IBM Rational entwickelt. 2012 als Disciplined Agile Delivery (DAD) in Buchform publiziert, erweitert zum breiteren Disciplined-Agile-(DA)-Toolkit, das Enterprise-Ebenen-Anliegen abdeckt. 2019 vom Project Management Institute (PMI) akquiriert, was PMI ein glaubwürdiges Agile-Asset und DA Enterprise-Distribution gibt. Choose Your WoW! (Ambler und Lines, aktuelle Ausgabe unter PMI) ist der kanonische Text.
Skalierungsannahme: Ein Toolkit statt eines einzelnen vorgeschriebenen Frameworks. DA unterstützt vier Lifecycles innerhalb eines Programms: agil (Scrum-basiert), lean (Continuous-Flow), explorativ (Lean-Startup) und traditionell (planbasiert). Teams wählen den Lifecycle, der zu ihrem Kontext passt, und das Toolkit leitet die Wahl mit Zieldiagrammen an.
Präskriptiv vs. flexibel: Wahlgetrieben, zielorientiert. Statt spezifische Praktiken vorzuschreiben, definiert DA Prozessziele („Team bilden", „Risiko adressieren", „Aktivitäten koordinieren") und präsentiert die Praxisoptionen zur Erreichung jedes Ziels mit ihren Trade-offs. Das Framework ist bewusst agnostisch, welche Praxis richtig ist, und verlangt stattdessen, dass Teams explizit wählen.
Governance-Form: Per Design pluralistisch. Das Toolkit akkommodiert traditionelle und agile Delivery im selben Programm — ein bewusstes Zugeständnis an Unternehmen mit regulierten Workstreams, vendor-gemanagten Projekten und rein agilen Produktteams, die parallel laufen.
Software-Engineering-Tiefe: Breit statt tief. Das Toolkit umfasst DevOps, Security, Architektur, Datenmanagement und Operations als benannte Zielbereiche. Der Trade-off: DA deckt mehr Themen ab als jedes einzelne Framework, geht aber bei den Engineering-Praktiken innerhalb jedes Themas weniger tief.
Wo es glänzt: Organisationen mit gemischten Delivery-Kontexten — manche Teams brauchen planbasierte Disziplin, andere fahren Lean-Startup-Experimente, wieder andere liefern Produkt auf Scrum, alles unter einem Programm. PMI-ausgerichtete Governance-Umgebungen, in denen PMP-geschulte Programmmanager einen Weg zu Agile brauchen, der ihre bestehenden Zertifizierungen respektiert. Post-Merger-Integrationen, in denen zwei Delivery-Kulturen koexistieren müssen, ohne dass eine der anderen untergeordnet wird.
Wo es falsch angewendet wird: Kleine Organisationen, die von der Breite des Toolkits überfordert sind und mit einem einzelnen vorgeschriebenen Framework besser bedient gewesen wären. Organisationen, die „PMI" auf dem Cover lesen und DA als „Agile für PMP-Shops" behandeln statt als das Toolkit, das es ist. Implementierungen, die DAs Flexibilität als Deckmantel nutzen, um nie eine Wahl zu treffen.
Einschätzung: Unterschätzt im Verhältnis zu seinem Umfang. PMI-Eigentümerschaft gab dem Framework Enterprise-Glaubwürdigkeit, verlangsamte aber die Community-Geschwindigkeit; die Konferenzen sind ruhiger als bei SAFe oder LeSS, die offenen Beiträge dünner. Das Framework, das am ehesten echte Arbeit in regulierten und Mixed-Portfolio-Umgebungen leistet, und am seltensten die Antwort ist, wenn eine Organisation sagt, sie wolle „agil werden".
Quellen: Ambler und Lines, Choose Your WoW! (PMI) · pmi.org/disciplined-agile · PMI-DA-Zertifizierungsstrom (DAC, DASM, DAVSC) · Ambler und Lines, Disciplined Agile Delivery (IBM Press, 2012)
6. Nexus
Autor / Herkunft: Ken Schwaber (Miterfinder von Scrum) und Scrum.org. Das Nexus Framework wurde erstmals 2015 veröffentlicht und in nachfolgenden Nexus-Guide-Updates verfeinert, wobei die aktuelle Version Scrum.orgs weiterentwickelte Praxis abdeckt. Explizit als minimal tragfähige Erweiterung von Scrum auf mehrere Teams an einem Produkt konzipiert.
Skalierungsannahme: Drei bis neun Scrum-Teams, die aus einem einzigen Product Backlog an einem integrierten Produktinkrement arbeiten. Über neun Teams empfehlen die Autoren des Frameworks entweder eine Umstrukturierung in mehrere Nexus-Instanzen oder ein anderes Framework in Betracht zu ziehen.
Präskriptiv vs. flexibel: Eng im Umfang, innerhalb dieses Umfangs präskriptiv. Nexus fügt nur hinzu, was strikt nötig ist, damit Multi-Team-Scrum funktioniert: ein Nexus Integration Team (eine Arbeitseinheit, keine separate Rollenhierarchie), Nexus-Ebenen-Events, die die Team-Ebenen-Scrum-Events einrahmen, und ein Nexus Sprint Goal, das das Inkrement zusammenhält. Sonst ändert sich nichts.
Governance-Form: Integrationsteam-zentriert. Das Nexus Integration Team ist für das integrierte Inkrement verantwortlich und dafür, Scrum-Teams in den Engineering-Praktiken zu coachen, die Integration möglich machen. Teamübergreifende Abhängigkeiten werden im Nexus Sprint Planning sichtbar gemacht und adressiert, statt der Ad-hoc-Koordination überlassen zu werden.
Software-Engineering-Tiefe: Explizit bei der Integrationsdisziplin. Die Definition of Done auf Nexus-Ebene erzwingt Engineering-Praktiken — Continuous Integration, Integrationstests, gemeinsames Tooling —, die auf Team-Ebene leicht übersprungen werden. In der Praxis liefert Nexus hier seinen Wert: indem es Integrationsdisziplin zur strukturellen Anforderung macht, nicht zu einem Coaching-Wunsch.
Wo es glänzt: Single-Produkt-Organisationen mit drei bis neun Teams, die Scrum bereits effektiv praktizieren und die minimale Prozessänderung wollen, die für die Skalierung nötig ist. Engineering-geführte Produktorganisationen, die sich dem Scrum.org-Ökosystem verpflichtet haben. Implementierungen, die ein gut integriertes Framework einem Portfolio-Overlay vorziehen.
Wo es falsch angewendet wird: Organisationen mit zehn oder mehr Teams, die Nexus übernehmen, weil sie es schon bei neun einsetzten und sich nicht zum Wechsel durchringen konnten. Organisationen mit schwachen Scrum-Fundamenten auf Team-Ebene, bei denen Nexus die bestehenden Dysfunktionen einfach auf eine höhere Koordinationsschicht hebt. Multi-Produkt-Portfolios, die nicht auf einen einzigen Backlog gezwungen werden sollten.
Einschätzung: Die Option „Scrum, nur etwas grösser". Geringere Markenoberfläche als SAFe oder LeSS, mit einem kleineren externen Consultant-Ökosystem. Sauberster Pfad für Organisationen, die bereits im Scrum.org-Trainingsstrom sind und ohne Umbenennung skalieren wollen. Das Framework, das in Framework-Debatten am häufigsten vergessen wird, weil es nicht versucht, diese Debatte zu gewinnen — es versucht, weiterhin Scrum zu sein.
Quellen: Schwaber und Scrum.org, The Nexus Guide · scrum.org/resources/nexus-guide · Scrum.org-Scaled-Professional-Scrum-(SPS)-Zertifizierung · Scrum.org-Community-Fallstudien
7. Kanban Maturity Model (KMM)
Autor / Herkunft: David J. Anderson und Teodora Bozheva, Kanban Maturity Model (Lean Kanban Inc., 2018; nachfolgende Revisionen). Anderson ist auch Autor des grundlegenden Kanban-Buchs (2010), das die Kanban-Methode in der Software-Delivery etablierte. Vertrieben über die Kanban University (früher Lean Kanban University) und die Mauvius Group.
Skalierungsannahme: Gilt auf Team-, Service-Delivery- und Enterprise-Ebene. Der Reifegrad ist in Stufen 0 bis 6 gestaffelt (sieben Stufen: Oblivious, Emerging, Defined, Managed, Established, Optimising, Congruent), wobei jede Stufe Praktiken hinzufügt, die auf der vorherigen aufbauen. Das Modell stellt explizit klar, dass für den Start keine Team-Struktur-Reorganisation nötig ist — eine Organisation kann KMM übernehmen, ohne ihr bestehendes Organigramm aufzulösen.
Präskriptiv vs. flexibel: Ein nach Reifegrad geordneter Praxiskatalog, kein einzelner vorgeschriebener Prozess. Die zentrale Prämisse des Frameworks — „beginne mit dem, was du jetzt tust; vereinbare, evolutionären Wandel zu verfolgen" — behandelt die bestehende Organisation als Ausgangspunkt und lässt die Praxisübernahme der Fähigkeit folgen.
Governance-Form: Flow-basiert und serviceorientiert. Arbeit wird als Strom von Nachfrage gegen Kapazität behandelt. Governance verschiebt sich von Projekt-und-Ressourcen-Denken zu Service Delivery, Classes of Service und expliziten Policies für unterschiedliche Nachfragetypen. Keine erforderlichen Rollenänderungen — die bestehende Organisationsstruktur bleibt bestehen.
Software-Engineering-Tiefe: Agnostisch. KMM konzentriert sich auf Workflow, Demand Management, Classes of Service und Policies; es bezieht keine Position zu spezifischen Engineering-Praktiken. Engineering-starke Teams behalten ihre Praktiken; Engineering-schwache Teams werden vom Framework nicht dazu gezwungen.
Wo es glänzt: Operations-lastige und Service-Delivery-Organisationen — IT-Operations, Infrastruktur-Teams, Support, regulierte Prozessarbeit. Organisationen, in denen Reorganisation politisch oder praktisch unmöglich ist. Reife Engineering-Shops, die Scrums Zeremoniendichte bereits abgelehnt haben und strukturelle Verbesserung wollen, ohne ihren bestehenden Flow zu verlieren.
Wo es falsch angewendet wird: Käufer aus Produktorganisationen, die Team-Struktur-Vorgaben erwarten und KMMs evolutionäre Haltung frustrierend finden. Implementierungen, die das Framework auf „ein Kanban-Board an die Wand hängen" reduzieren, ohne WIP-Limits, Classes of Service oder die nach Reifegrad gestaffelte Praxisprogression zu übernehmen. Organisationen, die KMM als Vorwand nutzen, um die schwerere organisatorische Arbeit zu vermeiden.
Einschätzung: Das Framework, zu dem Consultants greifen, wenn eine Organisation Scrum abgelehnt hat, aber trotzdem strukturelle Verbesserung braucht. Stilles, dauerhaftes Adoptionsmuster: weniger Flagship-Fallstudien als SAFe, geringere Markenoberfläche, aber hohe Bindung nach der Übernahme. Das am wenigsten diskutierte Framework in diesem Vergleich und eines der nützlichsten im richtigen organisatorischen Kontext.
Quellen: Anderson und Bozheva, Kanban Maturity Model (Lean Kanban Inc., 2018) · kanbanmaturitymodel.com · Kanban-University-Zertifizierung (KMP, KCP) · Anderson, Kanban: Successful Evolutionary Change for Your Technology Business (Blue Hole Press, 2010)
8. FAST — Fluid Agile Scaling Technology
Autor / Herkunft: Ron Quartel, ursprünglich 2017 aus seiner früheren Arbeit mit selbstorganisierenden Agile-Teams im grossen Massstab formuliert. Dokumentiert im FAST Guide, verfeinert durch nachfolgende Revisionen und Community-Beiträge auf fastagile.io. Das Framework schöpft aus den Prinzipien der Open Space Technology für Selbstorganisation und wendet sie in einem Software-Delivery-Kontext an.
Skalierungsannahme: Ein „Tribe" von typischerweise 30-150 Personen. Entscheidend: Teams sind nicht fix. Zu Beginn jeder kurzen Iteration (typischerweise zwei Tage bis eine Woche) organisieren sich Tribe-Mitglieder selbst rund um die Arbeitspakete, die ihnen wichtig sind, bilden für diese Iteration Teams und lösen sich am Ende wieder auf. Feste Scrum-Teams mit stabiler Mitgliedschaft existieren nicht.
Präskriptiv vs. flexibel: Radikal flexibel. Keine festen Scrum Master. Keine festen Product Owner. Keine festen Team-Besetzungen. Die strukturellen Vorgaben sind minimal: ein Tribe-Meeting zu Beginn jedes Zyklus, ein Marktplatz, auf dem Arbeit angeboten und übernommen wird, und leichtgewichtige Work Streams, die über Zyklen hinweg Kontinuität für länger laufende Anliegen sicherstellen.
Governance-Form: Selbstorganisierend und marktbasiert. Nachfrage wird im Tribe-Meeting sichtbar; Menschen wählen, woran sie arbeiten; Work-Stream-Verantwortliche sichern Kontinuität für Themen, die mehrere Zyklen überspannen. Das Modell stützt sich auf kollektive Verantwortlichkeit und transparente Sichtbarkeit statt auf benannte rollenbasierte Autorität.
Software-Engineering-Tiefe: Setzt eine reife Engineering-Kultur voraus. Kein eingebauter Ausgleich für schwache technische Fundamente. Ohne Trunk-Based Development, Continuous Integration, umfassende Testabdeckung und geteilte Code-Ownership produziert das fluide Team-Modell Chaos statt Autonomie. FAST verzeiht Engineering-Abkürzungen nicht, anders als die stärker strukturierten Frameworks.
Wo es glänzt: Technologisch reife Organisationen mit hohem Vertrauen, die bereit sind, feste Teamidentität zugunsten fluider Zusammenarbeit aufzulösen. Forschungsgruppen, Platform-Engineering-Teams, fortgeschrittene Produktorganisationen, deren Arbeit intrinsisch variabel ist. Organisationen, deren bestehende Engineering-Kultur stark genug ist, den Verlust von Team-Ebenen-Struktur zu absorbieren.
Wo es falsch angewendet wird: Organisationen, denen die von FAST vorausgesetzte Engineering-Disziplin fehlt — ohne Continuous Integration und eine starke Testbasis wird das tägliche Neusortieren des Frameworks zur täglichen Brandbekämpfung. Organisationen mit externen Verpflichtungen oder harten Lieferterminen, die die Vorhersagbarkeit fester Teams brauchen. Programme mit regulatorischen Anforderungen an benannte individuelle Verantwortlichkeit.
Einschätzung: Der Ausreisser. Corporate-Käufern fast unbekannt, gelegentlich von Senior Engineers als das im Kern agilste der Scaled-Frameworks zitiert. Das Framework, das am ehesten in einem Senior-Engineering-Gespräch darüber auftaucht, „was eigentlich funktionieren würde, wenn wir uns nicht an eine Beschaffungsvorlage halten müssten". Einflussreich weit über seinen Adoptions-Fussabdruck hinaus — Ideen aus FAST tauchen in den Entwicklungspfaden anderer Frameworks auf.
Quellen: Quartel, The FAST Guide (fastagile.io) · fastagile.io · FAST-Community-Talks und Fallstudien · Open-Space-Technology-Ursprungsmaterial (Owen, 1997)
Wie die grossen Firmen sie verpacken
Die zehn Firmen unten liefern Agile-Transformationen im grossen Stil. Jede hat ein benanntes Angebot, eine Verpackungsstory und (meist) einen benannten Flagship-Fall. Das Muster: eine Basismethode (meist SAFe, manchmal LeSS oder Spotify-inspiriert), plus die Signature-Wrapper der Firma (benannte Plattformen, Accelerators, Training), plus Zugang zu globalem Talent. Die Unterschiede stecken in den Wrappern.
BCG
Benanntes Angebot: Agile at Scale, angesiedelt unter den Practices People & Organization und Business Transformation. Das Signature-Diagnostikum ist „Agile Performance Management".
Verwendete Methoden: Spotify-inspirierte Tribe- und Squad-Strukturen bilden das dominante Muster in BCGs publizierten Agile-Fällen. SAFe-Koordinationsmuster erscheinen in Engagements regulierter Branchen. BCGs eigenes Portfolio-Governance-Overlay sitzt über welcher Basismethode das Engagement auch verwendet.
Signature-IP: BCG Agile Diagnostic, das Agile-Performance-Management-Framework, die Benchmark-Serie „Build for the Future". BCG X — die 2022 aus BCG GAMMA, BCG Platinion und BCG Digital Ventures zusammengeführte Technologie-Build-Einheit — liefert die Engineering-Seite grosser Transformationen.
Benannter Flagship-Fall: ING Banks „Spotify-inspirierte" Transformation von 2015-2018 ist BCGs meistzitierter öffentlicher Agile-Fall (gemeinsam mit McKinsey erzählt, deren Beteiligung ebenfalls öffentlich dokumentiert ist). Roche und mehrere grosse europäische Banken erscheinen in BCGs Fallstudienbibliothek.
Training/Zertifizierung: Interne BCG-Akademien für Consultants. Kein öffentlicher Zertifizierungsstrom. BCG X trägt Engineering-spezifisches Training intern.
Positionierungs-Vibe: Strategy-first. Agile wird als Operating-Model-Transformation positioniert, die auf C-Suite-Ebene verantwortet wird, wobei Engineering-Praxis ein nachgelagertes Anliegen ist, das BCG X oder die Engineering-Teams des Klienten übernehmen. Konzeptionell benachbart zu BCGs breiterer „10-20-70"-These aus dem KI-Beitrag — Agile liefert die 70 (Menschen, Prozess, Change).
Quellen: BCG.com Agile-at-Scale-Capability-Seite, Agile-Performance-Management-Publikationen, Berichterstattung zur ING-Transformationsfallstudie (BCG und Dritte). Snapshot-Datum wird während der Recherchesitzung fixiert; Firmenseiten aktualisieren sich häufig.
McKinsey & Company
Benanntes Angebot: Agile Transformation unter der Practice People & Organizational Performance, verankert im Diagnostikum „Five Trademarks of Agile Organizations". Das angrenzende Publishing von McKinsey Quarterly und McKinsey Insights dient als öffentlich sichtbare IP-Schicht.
Verwendete Methoden: Spotify-inspirierte Strukturen erscheinen in McKinseys publizierter Fallarbeit. SAFe-Muster-Koordination in Engagements regulierter Branchen. McKinseys eigenes Organisationsdesign-Overlay (Org Health Index, Influence Model) liegt über der Agile-Delivery-Arbeit.
Signature-IP: „The five trademarks of agile organizations" (Bazigos, De Smet, Gagnon, 2018) ist das dominante publizierte Asset — die fünf sind: ein in der ganzen Organisation verkörperter North Star, ein Netzwerk befähigter Teams, schnelle Entscheidungs- und Lernzyklen, ein dynamisches Personalmodell und Enabling Technology der nächsten Generation. Agile-Performance-Management-Essays und das Org-Health-Index-Agile-Diagnostikum runden die öffentliche IP ab.
Benannter Flagship-Fall: ING Banks Transformation von 2015-2018 (öffentlich gemeinsam mit BCG erzählt). Roches Agile-Transformation in F&E. Mehrere asiatische und europäische Banking-Transformationen im McKinsey Quarterly zitiert. Der von McKinsey verfasste ING-Fall ist die meistzitierte Agile-Transformation in der Wirtschaftsliteratur.
Training/Zertifizierung: Internes McKinsey-Praktikernetzwerk. Kein öffentlicher Zertifizierungsstrom. Das McKinsey-Forward-Trainingsprogramm (breitere Führungskräfteentwicklung) enthält Agile-Inhalte.
Positionierungs-Vibe: Agile als organisatorisches Designproblem. Gewicht auf Diagnostik, Umfragen und Operating-Model-Wandel statt auf Engineering-Praxis. Die Firma, die am ehesten ein Aufsichtsrat-Ebenen-Gespräch über Agile-Transformation führt, und die Firma, die am seltensten im Raum ist, wenn die CI-Pipeline konfiguriert wird.
Quellen: Bazigos, De Smet, Gagnon, „The five trademarks of agile organizations" (McKinsey, 2018) · McKinsey-Quarterly-Agile-Beiträge (Aghina, De Smet, andere, mehrere Jahre) · McKinsey-ING-Bank-Fallstudien. Snapshot-Datum wird während der Recherche fixiert.
Deloitte
Benanntes Angebot: Agile@Scale (in diversen Deloitte-Eigenschaften auch als „Agile at Scale" referenziert), gestützt durch ein Agile-Maturity-Model-Diagnostikum und das Agile Transformation Playbook.
Verwendete Methoden: SAFe ist die dominante Basismethode — Deloitte ist ein Scaled Agile Inc. Global Transformation Partner in der obersten Stufe des Partner-Ökosystems. LeSS- und Spotify-inspirierte Strukturen erscheinen, wo der Kontext passt, insbesondere in produktgeführten Engagements. Durchgehend Scrum auf Team-Ebene.
Signature-IP: Agile Maturity Model, Agile Transformation Playbook, SAFe-Partnerschaft-Accelerators, Agile@Scale-Capability-Seiten. Angrenzend: Das Trustworthy-AI-Framework (sieben Dimensionen, aus dem KI-Beitrag) teilt Governance-DNA mit Deloittes Agile-Governance-Ansatz.
Benannter Flagship-Fall: Transformationen im öffentlichen Sektor und im Finanzdienstleistungsbereich über US-, UK- und europäische Geografien hinweg. Spezifisch benannte Fälle variieren je Deloitte-Mitgliedsfirma; Flagship im Snapshot zu bestätigen.
Training/Zertifizierung: Eine der grössten SAFe-zertifizierten Consultant-Banken der Branche. Interne Deloitte Agile Academy. PMI-Disciplined-Agile-Partnerschaft für Hybrid-Programme.
Positionierungs-Vibe: SAFe-ausgerichtet, governance-freundlich, audit-bereit. Die Firma, die man engagiert, wenn Regulatoren im Raum sind und die Transformation eine Compliance-Prüfung überstehen muss. Weniger Produkt-Engineering-Tiefe als Capgemini oder IBM; mehr Programm-Governance-Tiefe als McKinsey oder Bain.
Quellen: Deloitte.com Agile@Scale-Capability-Seiten · Scaled-Agile-Inc.-Global-Transformation-Partner-Verzeichnis · Deloitte-Insights-Agile-Publikationen · regionale Agile-Maturity-Model-Beiträge. Snapshot-Datum wird während der Recherche fixiert.
EY (und EY-Parthenon)
Benanntes Angebot: Business Agility (in diversen EY-Eigenschaften auch als „Agile Business Reinvention" referenziert), positioniert innerhalb des breiteren Transformation-Realized-Frameworks.
Verwendete Methoden: In der Mehrheit der öffentlichen Fälle SAFe-ausgerichtet. Scrum auf Team-Ebene. EYs Change-Management-Overlay „Transformation Activation" liegt über der Agile-Delivery.
Signature-IP: Transformation-Realized-Framework (EYs übergreifende Transformationsmethodik, in die Business Agility als Delivery-Modell einsteckt). EY-Wavespace-Facilitation-Studios für Workshops und PI-artige Planungsevents. Angrenzend: EY.ai und die EYQ-Agentic-Platform (aus dem KI-Beitrag) — Agile-Delivery obendrauf auf EYs regulierten-Branchen-KI-Stack.
Benannter Flagship-Fall: Transformationen in regulierten Branchen (Finanzdienstleistungen, Regierung, Steuern). Spezifisch benannte Fälle variieren je EY-Mitgliedsfirma und Engagement-Vertraulichkeit; Flagship im Snapshot zu bestätigen.
Training/Zertifizierung: SAFe-Partner. Internes EY-Wavespace-Facilitation-Programm. EY-spezifische Change-Management-Zertifizierungen.
Positionierungs-Vibe: Transformations- und Change-lastig. Agile lebt innerhalb einer breiteren Change-Story, statt eigenständig zu stehen. Weniger Software-Engineering-Tiefe als Capgemini oder IBM; mehr Change-Management- und Stakeholder-Management-Tiefe als die meisten Peers. Die Firma, die man engagiert, wenn die Agile-Delivery das Mittel und die Restrukturierung der regulierten Branche der Zweck ist.
Quellen: EY.com Business-Agility- und Transformation-Realized-Capability-Seiten · EY-Wavespace-Publikationen · EY-Parthenon-Strategie- und Transformationsinsights. Snapshot-Datum wird während der Recherche fixiert.
PwC
Benanntes Angebot: Agile Transformation, positioniert unter der Business-Transformation-Practice, häufig gebündelt mit Digital-Transformation-Engagements. PwCs BXT-(Business-Experience-Technology)-Operating-Model bildet die übergreifende Transformationsarchitektur.
Verwendete Methoden: SAFe und Scrum@Scale erscheinen in PwCs publizierter Fallarbeit. Scrum auf Team-Ebene. Das BXT-Modell umhüllt, welche Basis-Agile-Methode das Engagement auch verwendet.
Signature-IP: BXT-Operating-Model (PwCs meistzitierte Transformations-IP — argumentiert, dass Business, Experience und Technology gemeinsam gestaltet und geführt werden müssen statt übergeben zu werden). Digital-Fitness-Assessment. Angrenzend: ChatPwC, der ~200.000-Seat-ChatGPT-Enterprise-Rollout (aus dem KI-Beitrag), ist das am stärksten skalierte interne GenAI-Tool jeder Firma in diesem Vergleich — Agile-Delivery-Teams liefern in einen GenAI-gesättigten Arbeitsplatz.
Benannter Flagship-Fall: Agile-Rollouts im Finanzdienstleistungsbereich über US-, UK- und europäische Märkte. Flagship im Snapshot zu bestätigen; PwCs Agile-Fallpublikation ist geringvolumiger als bei den Big-Four-Peers.
Training/Zertifizierung: SAFe-zertifizierte Bank. PwC-Academy-Programme. Internes BXT-Facilitator-Training.
Positionierungs-Vibe: Change-Management-geführt. Agile wird als Enterprise-Verhaltenstransformation präsentiert statt als Software-Engineering-Praxis. Weniger gebrandete Agile-spezifische Methodik als Deloitte oder Accenture — PwCs Agile-Arbeit geschieht innerhalb von Business Transformation statt als eigenständiges Angebot zu stehen.
Quellen: PwC.com Business-Transformation- und Digital-Transformation-Capability-Seiten · BXT-Methodik-Publikationen · PwC Global CEO Survey (Agile-bezogene Befunde). Snapshot-Datum wird während der Recherche fixiert.
KPMG
Benanntes Angebot: Agile Transformation, angesiedelt innerhalb des Connected-Enterprise-Capability-Frameworks, oft gepaart mit KPMG Powered Enterprise (KPMGs SaaS-beschleunigter Transformationsmethodik).
Verwendete Methoden: SAFe ist die dominante Basismethode in KPMGs publizierten Agile-Engagements. Scrum auf Team-Ebene. Connected Enterprise umhüllt die Agile-Delivery mit KPMGs Capability-Model-Assessment.
Signature-IP: Connected Enterprise (acht funktionale und kundenbezogene Capabilities für End-to-End-Transformation angeordnet), Powered Enterprise (vorkonfigurierte SaaS-Lösungs-Accelerators für ERP, HR, Finance und Operations), KPMG Lakehouse (der Flagship-Trainings- und Innovationscampus der Firma). Angrenzend: Das Trusted-AI-Framework (10 Säulen, aus dem KI-Beitrag) teilt Governance-DNA mit KPMGs Agile-Governance-Ansatz.
Benannter Flagship-Fall: Transformationen im Finanzdienstleistungs- und öffentlichen Sektor über UK, US und Asien-Pazifik hinweg. Spezifisch benannter Flagship-Fall im Snapshot zu bestätigen.
Training/Zertifizierung: SAFe-Partner. KPMG Lakehouse (Orlando, FL, und weitere Campusse) bietet immersives Training für Consultants und Klienten-Teams.
Positionierungs-Vibe: Capability-Model-geführt. Agile sitzt innerhalb eines breiteren Capability-Frameworks, statt das Herzstück zu bilden. KPMGs Audit-DNA trägt in das Agile-Governance-Design hinein — die Firma, die man engagiert, wenn die Agile-Transformation rückverfolgbare, auditierbare Governance-Artefakte produzieren muss. Die Nähe zum ISO/IEC-42001-First-Claim (aus dem KI-Beitrag) verstärkt die Governance-Haltung.
Quellen: KPMG.com Agile-Transformation- und Connected-Enterprise-Capability-Seiten · KPMG-Powered-Enterprise-Publikationen · KPMG-Lakehouse-Programmüberblick. Snapshot-Datum wird während der Recherche fixiert.
Accenture
Benanntes Angebot: Business Agility innerhalb der Strategy-&-Consulting-Practice; Agile Engineering Studios innerhalb der Technology-Practice; Agile-und-DevOps-Services innerhalb von Operations. Accentures Agile-Capability erstreckt sich über drei der vier Service-Lines der Firma.
Verwendete Methoden: SAFe ist die dominante Basismethode, wobei Accenture zu den grössten SAFe Global Transformation Partners zählt. Spotify-inspirierte Strukturen erscheinen in tech-nativen Engagements. Durchgehend Scrum auf Team-Ebene. Das myConcerto-Branchenlösungs-Overlay liegt über der Agile-Delivery.
Signature-IP: myConcerto (branchenausgerichteter Lösungs-Accelerator), Agile Engineering Studios (regionale Engineering-Hubs), ADM und ADMnext (Application Development & Maintenance — das Engineering-Services-Delivery-Overlay; ADMnext ist die umbenannte Next-Generation-Version). Angrenzend: AI Refinery und das 3-Mrd.-USD-KI-Investment (aus dem KI-Beitrag) — Agile-Teams liefern auf Refinery; die Accenture-NVIDIA Business Group ist die meistgebrandete Hyperscaler-Allianz im Consulting.
Benannter Flagship-Fall: Mehrere öffentlich zitierte Fortune-500-Transformationen über Finanzdienstleistungen, Retail, Gesundheitswesen und Industrie hinweg. Spezifisch benannter Flagship im Snapshot zu bestätigen; Accentures Fallstudienvolumen zählt zu den höchsten der Branche.
Training/Zertifizierung: Plausibel die grösste SAFe-zertifizierte Consultant-Bank jeder Firma (zehntausende Zertifizierungen über die globale Belegschaft). Accenture Academy. Agile Engineering Studios als Bank-Entwicklungsmotor.
Positionierungs-Vibe: Skala und Ausführung. Agile sitzt innerhalb Accentures breiterem Engineering-Services-Angebot statt als eigenständige Transformation. Die Firma, die man engagiert, wenn die Transformation globale Delivery, Multi-Vendor-Koordination und eine SAFe-zertifizierte Bank auf Abruf braucht. Weniger Senior-Partner-geführtes Narrativ als McKinsey oder Bain; mehr Ausführungsmotor-Tiefe als jeder Peer.
Quellen: Accenture.com Business-Agility-, Agile-Engineering-Studios- und myConcerto-Capability-Seiten · Scaled-Agile-Global-Transformation-Partner-Verzeichnis · ADM- und ADMnext-Publikationen · Accenture-NVIDIA-Business-Group-Ankündigungen. Snapshot-Datum wird während der Recherche fixiert.
Bain & Company
Benanntes Angebot: Agile Innovation (Bains markantestes publiziertes Agile-Angebot), gestützt durch das Bain Agile Innovation Network und das Agile-Enterprise-Diagnostikum auf Portfolio-Ebene.
Verwendete Methoden: Scrum auf Team-Ebene. Bains eigenes Agile-Enterprise-Diagnostikum auf Portfolio-Ebene. Weniger Framework-präskriptiv als die Big Four; Bain arbeitet auf der strategischen und Operating-Model-Schicht und lässt das gewählte Team-Ebenen-Framework sich dem Engagement anpassen.
Signature-IP: Darrell Rigby (Bain-Partner, inzwischen im Ruhestand, aber mit anhaltender Thought-Leadership-Präsenz) war Mitautor von Doing Agile Right (Harvard Business Review Press, 2020) — Bains meistpublizierte Agile-Asset. Frühere HBR-Artikel umfassen „Embracing Agile" (2016), „Agile at Scale" (2018) und „The Agile C-Suite" (2020). Angrenzend: Sage (internes GPT-4-basiertes Tool, aus dem KI-Beitrag) und die OpenAI-Allianz — Agile-Teams liefern gemeinsam gestaltete KI-Arbeit auf gebrandeten Allianz-Assets.
Benannter Flagship-Fall: John Deere (Fertigungs-Agile, ausführlich von Rigby zitiert), Bosch (industrielle Agile-Transformation), plus mehrere Fälle im Rigby-HBR-Katalog. Die publizierte Fallbasis ist für eine Strategiefirma ungewöhnlich gründlich.
Training/Zertifizierung: Interne Bain Agile Innovation Practice. Kein öffentlicher Zertifizierungsstrom. Das Rigby-Buch und die HBR-Artikel fungieren als Bains externer Wissenstransfer.
Positionierungs-Vibe: Agile als Innovationsdisziplin statt IT-Delivery-Methode. Senior-Partner-geführtes Narrativ. Die Firma, die am ehesten im Raum ist, wenn ein Industriehersteller Agile in die Produktentwicklung einführen will, ohne die IT-Delivery umzustrukturieren. Weniger Zeremonie, mehr Strategie.
Quellen: Bain.com Agile-Innovation-Capability-Seiten · Rigby, Sutherland und Takeuchi, Doing Agile Right (HBR Press, 2020) · Rigby et al., HBR-Artikel 2016-2020 · Bain Technology Report (jährlich). Snapshot-Datum wird während der Recherche fixiert.
Capgemini
Benanntes Angebot: ADMnext (Application Development & Maintenance, agile- und DevOps-nativ — Capgeminis Flagship-Engineering-Services-Plattform), gestützt durch Agile- und Scaled-Agile-Services und die Capgemini Agile Innovation Centers.
Verwendete Methoden: SAFe ist die dominante Basismethode — Capgemini ist ein Scaled Agile Global Transformation Partner. Scrum, Kanban und DevOps sind integriert statt separat übereinandergelegt; Engineering-Praxis und Agile-Praxis kommen zusammen.
Signature-IP: ADMnext-Plattform (das meistzitierte Engineering-Services-Delivery-Asset in diesem Vergleich), Capgemini Agile Innovation Centers (regionale Engineering-Studios). Angrenzend: Das Resonance-AI-Framework (aus dem KI-Beitrag) sitzt über der Engineering-Plattform; Capgeminis Status als Google Cloud Partner of the Year 2025 verstärkt die Engineering-geführte Neigung.
Benannter Flagship-Fall: Europäische Banking-, Automobil- und Energietransformationen. Mercedes-Benz, BNP Paribas und mehrere grosse europäische Retailer werden häufig genannt. Spezifischer Flagship im Snapshot zu bestätigen; Capgeminis Fallbibliothek ist stark europazentriert und substanziell Engineering-geführt.
Training/Zertifizierung: Eine der grössten SAFe-zertifizierten Banken ausserhalb von Accenture. Capgemini University (der Flagship-Trainingscampus der Firma, Frankreich). Interne ADMnext-Praktiker-Zertifizierung.
Positionierungs-Vibe: Engineering-geführt. Die Firma, die am ehesten im Raum ist, wenn die Agile-Transformation untrennbar mit einem Platform-Engineering-, DevOps- oder Cloud-Modernisierungsprogramm verbunden ist. Starke europäische Markenautorität. Weniger Senior-Partner-Narrativ als McKinsey oder Bain; mehr Delivery-Engineering-Tiefe als Deloitte oder KPMG.
Quellen: Capgemini.com ADMnext-, Agile-Services- und Agile-Innovation-Center-Seiten · Scaled-Agile-Global-Transformation-Partner-Verzeichnis · Capgemini-Research-Institute-(CRI)-Publikationen. Snapshot-Datum wird während der Recherche fixiert.
IBM Consulting
Benanntes Angebot: IBM Garage Method (die kanonische Agile-plus-Engineering-Delivery-Methodik der Firma), am Front-End umhüllt von Enterprise Design Thinking und SAFe-ausgerichteter Koordination bei Skalierung. Geliefert über IBM-Garage-Standorte (physische und virtuelle Studios).
Verwendete Methoden: SAFe auf Programm-Ebene — IBM ist ein SAFe Global Transformation Partner. Scrum auf Team-Ebene. Enterprise Design Thinking am Anfang des Loops. Die Garage Method integriert diese in einen einzigen Discover-Envision-Develop-Reason-Operate-Culture-Zyklus.
Signature-IP: IBM Garage Method — die Heritage-IP, die IBM am stärksten von den Big Four unterscheidet. Enterprise Design Thinking (IBMs designgeführter Ansatz zur Problemrahmung). Historische Abstammung vom Rational Unified Process (RUP), IBMs ursprünglicher schwergewichtiger iterativer Methodik, 2003 mit Rational Software akquiriert. Angrenzend: IBM Consulting Advantage und watsonx (aus dem KI-Beitrag) — Agile-Delivery-Teams liefern auf die Advantage-Plattform und den watsonx-Modellstack.
Benannter Flagship-Fall: American Airlines (Garage-geführte Transformation, öffentlich dokumentiert), USAA (Garage-Engagement im Finanzdienstleistungsbereich), Travelport, mehrere Banking-Transformationen. Das Garage-Method-Playbook enthält substanzielles Fallmaterial.
Training/Zertifizierung: IBM Skills Academy. SAFe-Partner. Interner Garage-Method-Zertifizierungsstrom für IBM-Consultants. Enterprise-Design-Thinking-Zertifizierung.
Positionierungs-Vibe: Design-Thinking-zu-Engineering integriert. Die Firma, die am ehesten im Raum ist, wenn das Engagement mit einer designgeführten Problemrahmungs-Übung beginnt und mit Platform-Engineering-Delivery endet. Asset-lastig (Garage Method, watsonx, Enterprise Design Thinking) statt zeremonienlastig. Die klarste Engineering-und-Design-Abstammung jeder Firma in diesem Vergleich.
Quellen: IBM.com/garage-Capability-Seiten · IBM-Garage-Method-Playbook (ibm.com/cloud/architecture oder Nachfolge-URL) · Enterprise-Design-Thinking-Seiten · IBM-Consulting-Agile- und Transformationspublikationen. Snapshot-Datum wird während der Recherche fixiert.
Die Master-Vergleichstabelle
Die Tabelle unten ist das Referenz-Asset. Sie kreuzt die acht Frameworks gegen acht Vergleichsdimensionen, wobei die Firmen, die jedes Framework am aktivsten verpacken, in der rechten Spalte benannt sind.
| Framework | Primärautor | Skalierungsannahme | Präskriptions-Level | Governance-Form | Engineering-Tiefe | Zertifizierungs-Ökosystem | Aktivste Firmen-Verpacker |
|---|---|---|---|---|---|---|---|
| SAFe | Dean Leffingwell (Scaled Agile Inc.) | 50-125 pro ART; Portfolio > 1.000 | Hoch | Hierarchisch (Portfolio → Team) | DevOps + XP benannt | SAFe SPC/SA/POPM/etc. (Scaled Agile Inc.) | Accenture · Deloitte · Capgemini · IBM · EY |
| LeSS | Craig Larman / Bas Vodde (LeSS Company) | 2-8 Teams (LeSS); 8+ Teams (LeSS Huge) | Niedrig-mittel | Flach (ein PO) | Hoch (technische Exzellenz) | CLP, CLT (LeSS Company) | Kleinere Spezialisten; teilweise genutzt von McKinsey, Bain |
| Scrum@Scale | Jeff Sutherland (Scrum Inc.) | Modular; SoS-Struktur | Niedrig (modularer Kern) | Zwei Zyklen (PO + SM) | Mittel (trainingsabhängig) | SSM / SPS (Scrum Inc.) | BCG (selektiv); unabhängige Consultants |
| Spotify-Modell | Henrik Kniberg / Anders Ivarsson | Tribes / Squads (keine feste Grösse) | Kulturell, nicht strukturell | Matrix (Tribe × Chapter) | Implizit hoch (Spotify Engineering) | Keine offizielle | BCG (ING) · McKinsey · digital-native Beratungen |
| Disciplined Agile (DAD) | Scott Ambler / Mark Lines (PMI) | Toolkit; Lifecycle-agnostisch | Wahlgetrieben (zielorientiert) | Pluralistisch (agil/lean/planbasiert) | Breit (DevOps, Security, Architektur) | DAC, DASM, DAVSC (PMI) | PMI-ausgerichtete Firmen; IBM-Erbe |
| Nexus | Ken Schwaber (Scrum.org) | 3-9 Scrum-Teams, ein Produkt | Niedrig (Scrum-Erweiterung) | Integrationsteam-zentriert | Mittel (Integrationsdisziplin) | SPS, NXTC (Scrum.org) | Scrum.org-ausgerichtete Beratungen; teilweise Accenture |
| Kanban Maturity Model (KMM) | David J. Anderson (Mauvius Group) | Team bis Enterprise, Reifegradstufen 0-7 | Praxiskatalog | Flow-basiert, evolutionär | Agnostisch | KMP, KCP (Kanban University) | Operations-lastige Firmen; teilweise Capgemini |
| FAST | Ron Quartel | Tribe von 30-150, dynamische Teams | Radikal flexibel | Tribe-Meeting / Marktplatz | Hoch (setzt reife Praxis voraus) | Keine mainstream | Spezialisierte Coaches; selten grosse Firmen |
Was wirklich anders ist
- Nur drei Frameworks publizieren eine nummerierte Methodik, die man ohne Consultant implementieren kann. SAFe hat Rollen, Zeremonien, Artefakte und eine Continuous Delivery Pipeline, die ein Transformationsteam lesen und ausführen kann. LeSS hat die publizierten Regeln von Multi-Team-Scrum an einem Produkt. Scrum@Scale hat das SoS und die zwei Koordinationszyklen. Die anderen fünf — Spotify, DAD, Nexus, KMM, FAST — sind entweder Toolkits, Momentaufnahmen oder minimale Erweiterungen, die entweder einen erfahrenen Praktiker oder einen substanziellen bestehenden Kontext brauchen, um zu landen. Das ist kein Qualitätsurteil: Toolkits und Momentaufnahmen sind manchmal die richtige Antwort. Es ist ein Käuferklarheits-Urteil: Nur drei der acht Frameworks reduzieren die Consultant-Abhängigkeit, die das Framework eigentlich reduzieren sollte.
- Software-Engineering-Tiefe ist die sauberste Trennlinie im Feld. LeSS und FAST setzen reife Engineering-Praxis voraus und verzeihen deren Fehlen nicht. SAFe und Nexus benennen Engineering-Praktiken explizit in ihren Guides, verlassen sich aber darauf, dass der Implementierer sie mitbringt. Spotify, DAD, KMM und Scrum@Scale sind grösstenteils agnostisch bei der Engineering-Praxis. Ein Käufer, der die Engineering-Kultur seiner Organisation ehrlich kennt, kann diese Spalte direkt auf die Framework-Passung abbilden; ein Käufer, der es nicht weiss, übernimmt ein Framework, das die Lücke schmerzhaft offenlegt.
- Nur zwei Frameworks haben Zertifizierungsprogramme in Grossfirmen-Klasse. SAFe (Scaled Agile Inc., dominant, mehrere rollenausgerichtete Zertifizierungen, grosses Partner-Ökosystem) und Disciplined Agile (seit 2019 im Besitz von PMI, integriert mit dem PMP-Credential). Die anderen sechs haben Zertifizierungen — LeSS Company, Scrum.org Nexus, Scrum Inc. Scrum@Scale, Kanban University KMP, fastagile.io-Community —, aber Volumen und Durchdringung bei Beratungen sind um eine Grössenordnung niedriger. Das treibt einen Folgeeffekt, den Käufer selten sehen: Der SAFe-gesättigte Talentmarkt bedeutet, dass SAFe-Expertise auf Abruf echt verfügbar ist — bei LeSS oder FAST im Enterprise-Massstab ist das nicht der Fall.
- Das Spotify-Modell ist das meistzitierte und am wenigsten implementierte Artefakt im Feld. Es ist kein Framework. Das Originalpapier von 2012 beschrieb, was Spotify damals tat; die späteren Retrospektiven (Sundén 2017, andere) stellen klar, dass Spotify selbst sich innerhalb ein bis zwei Jahren über diese Diagramme hinausbewegt hat. Trotzdem verwendet jede Beratung in diesem Vergleich irgendeine Version von „Tribes" und „Squads" in ihrem Agile-Material, und ein erheblicher Anteil öffentlicher Agile-Transformationen zitiert Spotify als das Modell. Das Vokabular reist; die Engineering-Kultur, das Produktmanagement-Investment und die Plattforminfrastruktur, die die Spotify-Struktur zum Funktionieren brachten, tun das nicht.
- FAST und Kanban Maturity Model sind die einzigen Frameworks, die keine Team-Struktur-Reorganisation erfordern. Jedes andere Framework in dieser Liste setzt irgendeine Form expliziter Teamkonfiguration voraus, ob vorgeschrieben (SAFe ARTs, LeSS-Feature-Teams, Nexus-Scrum-Teams) oder beschreibend (Spotify-Squads). KMM arbeitet mit der bestehenden Struktur; FAST löst stabile Struktur vollständig zugunsten fluider Tagesbildung auf. Für Organisationen, in denen Reorganisation politisch oder praktisch unmöglich ist — Post-Merger-Kontexte, regulierte Strukturen, Organisationen, die sich von einer zuvor gescheiterten Transformation erholen —, ist das die sauberste Trennlinie im Feld.
- Drei Firmen publizieren substanzielle Methodik-IP, die nicht nur SAFe umbenennt. Bain (Rigbys Buch Doing Agile Right und die HBR-Artikelserie) hat eine publizierte Methodik mit einer eigenen Theorie darüber, wo Agile in eine Unternehmensstrategie passt. McKinsey (die Five Trademarks of Agile Organizations) hat ein Aufsichtsratssaal-Diagnostikum, das über jedem Framework operiert. IBM (die Garage Method und Enterprise Design Thinking, mit Erbe aus dem Rational Unified Process) hat die am längsten laufende publizierte Delivery-Methodik im Feld. Die anderen sieben Firmen operieren substanziell als SAFe-Partner mit gebrandeten Wrappern, selbst wo ihr öffentliches Material andere Methoden referenziert.
Was meist nur Branding ist
- Die meisten „Agile-Transformationsangebote" der Big Four sind SAFe mit firmengebrandetem Wrapper. Entfernt man das gebrandete Diagnostikum, die firmengefärbte PI-Planning-Vorlage und das proprietäre Reifegradmodell, ist die zugrundeliegende Basismethode bei sieben der zehn Firmen in diesem Beitrag SAFe (Ausnahmen sind Bain, McKinseys diagnostikgeführtes Narrativ und IBMs Garage Method). Das ist keine Kritik an SAFe und keine Kritik an den Firmen — SAFe hat sich seinen Marktanteil verdient —, aber ein Käufer sollte wissen, ob die IP der Firma der Wrapper oder die Basis ist.
- „Tribes und Squads" ist zu einem Vokabular geworden, nicht zu einer Methode. Fast jede Firma in diesem Vergleich verwendet Spotify-abgeleitete Sprache in ihrem Agile-Material. Fast keine liefert die Engineering-Kultur, die Produktmanagement-Disziplin oder das interne Plattform-Investment, das die Spotify-Struktur zum Funktionieren brachte. Wenn eine Firma das Spotify-Vokabular verwendet, ohne zu benennen, was sie bei Engineering-Praktiken, internen Developer-Plattformen und dem Produktmanagement-Operating-Model tun wird, ist das Vokabular als Branding zu behandeln.
- Agile-Reifegradmodelle sind meist selbstähnlich. Vier bis fünf Stufen. Dieselbe Handvoll Achsen — meist eine Kombination aus Prozess, Menschen, Technologie, Kultur und Kundenergebnissen. Vergleicht man die Agile-Reifegradmodelle dreier beliebiger Firmen nebeneinander, ist die strukturelle Ähnlichkeit auffällig. Das Reifegradmodell dient einem spezifischen Zweck — es macht das Engagement für ein Steering Committee lesbar —, ist aber selten die eigentliche Delivery-IP der Firma. Die IP steckt in den Consultants, die die Organisation durch die Stufen führen.
- Das SAFe-Zertifizierungsvolumen signalisiert weniger als früher. Der Zertifizierungsstrom ist gross, die Massentrainings-Pipeline ist reif, und die Halbwertszeit einer frischen Zertifizierung ist nicht mehr, was sie vor einem Jahrzehnt war. Eine Zahl SAFe-zertifizierter Consultants sagt, wie viele Personen die Firma durch einen Kurs geschickt hat, nicht wie viele eine Agile-Transformation geliefert haben, die eine Fünf-Jahres-Überprüfung überstanden hat. Fragen Sie nach der Zahl gelieferter Engagements, nicht nach der Zertifizierungszahl.
- Die meisten „Flagship-Fälle" überstehen keine ehrliche Fünf-Jahres-Überprüfung. Die meistzitierte Transformation der modernen Ära — ING Banks Spotify-inspirierte Restrukturierung von 2015-2018, erzählt von BCG und McKinsey — hat sich in den Jahren seither substanziell weiterentwickelt, und die heutige ING-Organisation sieht deutlich anders aus als das Diagramm von 2017. Dieses Muster ist nicht ING-spezifisch; es ist die Regel, nicht die Ausnahme. Der publizierte Flagship-Fall einer Firma ist eine Momentaufnahme eines Augenblicks in einem langen Programm. Fragen Sie, wie der Fall heute aussieht, nicht, wie das Deck sagte, er werde aussehen.
Die Realität 2026: KI, kleinere Teams, Platform Engineering
Jedes Framework in diesem Vergleich wurde entworfen, bevor generative KI die Grösse des Teams veränderte, das ein gegebenes Arbeitspaket liefert. Die Implikationen zeigen sich noch nicht in den Framework-Guides — SAFe 6.0 macht nur bescheidene Gesten in Richtung KI, der LeSS-Guide schweigt, die Spotify-Modell-Retrospektiven datieren vor dem aktuellen KI-Moment —, aber sie sind in den Transformationen von 2026 sichtbar.
Generative KI komprimiert die Teamgrösse. Ein Produkt-Arbeitspaket, das 2018 einen Tribe von achtzig Ingenieuren, Designern und Produktmanagern brauchte, ist 2026 in vielen Fällen mit acht bis fünfzehn Personen lieferbar, mit KI-gestützter Entwicklung, KI-generierter Testabdeckung und KI-unterstütztem Design. Die für Headcount-lastige Programme gebauten Frameworks — insbesondere SAFe auf ART-Ebene mit seiner 50-125-Personen-Annahme und der PI-Planning-Logistik — stehen unter strukturellem Druck. Die Frameworks, die sauber herunterskalieren (FAST, KMM, Nexus und LeSS am unteren Ende seiner Spanne), gewinnen still an Boden.
Platform Engineering ersetzt manche Koordinationszeremonien. Interne Developer-Plattformen erledigen jetzt die teamübergreifende Arbeit, die früher in Scrum-of-Scrums-Meetings, PI-Planning-Räumen und Integrationsteam-Ritualen stattfand. Wenn die Plattform die Koordination absorbiert, braucht das Framework weniger davon. Die Agile-Frameworks unter dem grössten Druck sind jene, deren Wertversprechen substanziell „Koordinationszeremonien und gemeinsame Kadenz" war. Die am stärksten gestärkten Frameworks sind jene, deren Wertversprechen substanziell „Engineering-Praxis und Flow" war.
Remote-first verändert die Ökonomie ortsgebundener Zeremonien. PI Planning über Zoom ist nicht, was PI Planning in einem Konferenzzentrum mit achtzig Personen und Klebezetteln war. Die Frameworks, die von einer bestimmten Vor-Ort-Ritualqualität abhingen, sind schwächer als früher; die Frameworks, die über jedes Kommunikationsmedium funktionierten (KMMs Flow-Boards, Nexus' Integrationsdisziplin), haben sich besser gehalten. Das ist kein Urteil über Remote-Arbeit; es ist eine Beobachtung darüber, welche Frameworks ihre Zeremonien in das Wertversprechen eingepreist hatten.
Die Entscheidungsregel hat sich verschoben. Die Framework-Auswahlfrage von 2018 war „welches Framework skaliert?". 2026 ist sie näher an „welches Framework übersteht eine fünfzigprozentige Headcount-Kürzung, ohne seine Identität zu verlieren?". SAFe-auf-Portfolio-Ebene übersteht die Kürzung durch Reduktion der ART-Zahl, aber ein SAFe-ART selbst wirkt bei unter fünfzig Personen unpassend. LeSS skaliert sauber auf zwei Teams herunter. KMM erfordert überhaupt keine headcount-definierte Struktur. Spotify-artige Tribes verlieren ihre Identität, wenn der Tribe auf einen Squad zusammenschrumpft.
Diese Verschiebung knüpft direkt an die Käuferfrage an, die wir im Begleitbeitrag Die grossen Beratungs-KI-Frameworks im Vergleich untersucht haben. KI ist nicht nur eine Technologie zum Deployen; sie ist eine Veränderung der Stückkostenökonomie von Software-Delivery. Das Agile-Framework, das zu einer KI-gesättigten Organisation von 2026 passt, ist selten dasselbe Agile-Framework, das zur selben Organisation 2018 passte, selbst wenn sich sonst nichts an der Arbeit geändert hat. Die Frameworks, die in diesem Umfeld am stärksten wirken, sind jene, die um Flow und Engineering-Praxis gebaut sind; die schwächsten sind jene, die um Headcount-lastige Koordination gebaut sind.
Wie man das als Käufer liest
Wenn Sie CEO, Aufsichtsratsmitglied, Transformation Officer oder PE-Investor sind, ist die Framework-Debatte fast nie der nützlichste Ort, um Ihre Entscheidungsenergie zu investieren. Die fünf Szenarien unten decken das meiste ab, was tatsächlich in Agile-Transformationsangeboten auftaucht; wählen Sie das passende Szenario, sehen Sie, was die Framework-Passung sagt, und nutzen Sie die drei Fragen am Ende, um den Pitch jeder Firma in fünf Minuten zu lesen.
Szenario 1 — Mid-Market-Skalierung (300-2.000 Mitarbeitende, schnell wachsend). Die richtige Antwort ist selten SAFe; es ist zu schwer für diese Grösse, und das Zertifizierungs-Ökosystem ist auf grössere Unternehmen kalibriert. Schauen Sie sich Scrum@Scale oder LeSS am unteren Ende seiner Spanne an. Die Firmenwahl ist typischerweise eine spezialisierte Agile-Beratung oder ein erfahrener unabhängiger Praktiker; die Big Four sind auf grössere Engagements kalibriert, und die Zugangskosten sind hoch im Verhältnis zum Wert, den Sie bei dieser Grösse herausholen.
Szenario 2 — Regulierte Branche (Banking, Pharma, regulierte Versorger, Verteidigung). SAFe gewinnt bei Audit-Freundlichkeit mit weitem Abstand — benannte Rollen, rückverfolgbare Artefakte, zertifizierte Consultants, die Beschaffungsfilter passieren. Die Firmenwahl ist Deloitte, Accenture, Capgemini, KPMG oder EY, je nach regionaler Präsenz und bestehender Beziehung. Der Trade-off, den Sie eingehen: Engineering-Praxis-Tiefe gegen Governance-Lesbarkeit; budgetieren Sie separat, um die Engineering-Lücke zu füllen.
Szenario 3 — Post-Merger-Integration. Zwei Delivery-Kulturen, oft zwei Delivery-Toolchains, oft zwei bestehende Agile-Ausprägungen, die sich widersprechen. DADs pluralistisches Lifecycle-Modell passt zu diesem Muster besser als jedes Ein-Philosophie-Framework; KMM funktioniert gut, wenn Reorganisation politisch vom Tisch ist. PMI-ausgerichtete Firmen oder spezialisierte Post-Merger-Integrationsberatungen. Vermeiden Sie es, eine Seite auf das Framework der anderen als Integrationsbewegung zu zwingen — die politischen Kosten rechtfertigen selten die methodologische Reinheit.
Szenario 4 — KI-lastiges Programm. Kleinere Teams, schnellere Zyklen, Platform-Engineering-abhängig. FAST oder LeSS am unteren Ende passen besser als SAFe; KMM funktioniert für die Operations-Seite desselben Programms. Die Firmenwahl überschneidet sich substanziell mit der KI-Beratungs-Entscheidung — siehe den Begleitbeitrag zu KI für diese Auswahl. Das Agile-Framework ist die Delivery-Schicht für die KI-Arbeit; wählen Sie es nach Engineering-Praxis-Passung, nicht nach Zeremoniendichte.
Szenario 5 — Klassischer IT-zu-Produkt-Wandel. Eine traditionelle IT-Delivery-Organisation bewegt sich zu produktgeführten, ergebnisorientierten Teams. Spotify-inspirierte Strukturen mit tiefem Engineering-Kultur-Investment sind die Lehrbuchantwort; das Lehrbuch wird oft falsch gelesen. BCG oder McKinsey liefern das Organisationsdesign-Overlay und das Aufsichtsrats-Ebenen-Narrativ; die Engineering-Arbeit ist der schwierige Teil und selten der Teil, den die Strategiefirma am besten liefern kann. Planen Sie ein zweites, Engineering-geführtes Engagement — Capgemini oder eine spezialisierte Platform-Engineering-Firma — neben der Strategiearbeit ein.
Drei Fragen schneiden schneller durch den Pitch einer Firma als jede Scoring-Matrix:
- „Zeigen Sie mir die Engineering-Praxis, die Ihr Team liefern wird, im Detail, am Montag." Wenn eine Firma die Engineering-Praxis ihres Teams — Trunk-Based Development, CI-Konfiguration, Testabdeckungs-Ansatz, Code-Review-Disziplin, Plattform-Tooling — nicht im Detail beschreiben kann, kaufen Sie Zeremonie, keine Delivery. Das kann manchmal die richtige Entscheidung sein. Wissen Sie nur, dass Sie sie treffen.
- „Zeigen Sie mir, wie die Struktur Ihres letzten Engagements heute aussieht." Frameworks entwickeln sich weiter, und die ehrliche Antwort zeigt, was den Kontakt mit der Organisation überlebt hat. Firmen, die Ihnen nicht sagen können, wie ihr letztes Engagement 2026 aussieht, sind entweder nicht in die Post-Engagement-Realität eingebunden oder unwillig, sie zu teilen. Beides sind nützliche Signale.
- „Wer verantwortet die Integrationsarbeit zwischen Teams, und wie ist sie besetzt?" Koordination sind die echten Kosten von Scaled Agile. Das häufigste Fehlschlagsmuster ist ein Framework, das die Integrationsrolle auf einer Folie benennt und sie im Engagement unbesetzt lässt. Fragen Sie wer, fragen Sie nach dem Lebenslauf, fragen Sie nach der Berichtslinie. Wenn die Antworten vage sind, wird die Integration in Delivery-Verzögerungen bezahlt werden.
Wo Consulting Huber passt
Consulting Huber ist eine Praktiker-Firma, kein Big-Four- oder MBB-Peer. Wir konkurrieren nicht über die Grösse der SAFe-zertifizierten Bank, über globale Delivery-Präsenz oder über das Volumen benannter Flagship-Fälle. Wir konkurrieren am entgegengesetzten Problem: Transformation Officers, CEOs, Aufsichtsräte und PE-Investoren, die die Methodik und die Engineering-Disziplin einer grossen Firma wollen, direkt geliefert von Senior Practitioners, mit der Fähigkeit am Ende des Engagements auf das eigene Team des Klienten übertragen.
Das bedeutet: Wir sagen Ihnen, welches Framework tatsächlich zur Engineering-Kultur Ihrer Organisation passt, statt welches Framework unser Zertifizierungsstack bevorzugt. Es bedeutet, dass wir mit Ihnen zusammenarbeiten, um die Integrationsrolle richtig zu besetzen, statt sie nur auf einer Folie zu benennen. Es bedeutet, dass wir Ihnen das Recht lassen, uns am Ende jedes Zyklus zu entlassen, weil das Modell Fähigkeitstransfer ist, kein Plattform-Lock-in.
Der Begleitbeitrag zur KI-Seite — wie dieselben zehn Firmen KI- und GenAI-Transformation framen, mit derselben Käuferperspektive — findet sich unter Die grossen Beratungs-KI-Frameworks im Vergleich (2026). Unsere Leistungsseite zur End-to-End-Agile-Arbeit ist unter Business Agility. Wenn Sie die KI-und-Agile-Brücke sehen wollen, wie diese beiden Beiträge sich für ein echtes Programm verbinden, ist das KI-Wertschöpfungs-Playbook die dritte Ecke des Dreiecks.
Konsultierte Quellen
Primärquellen — kanonische Framework-Texte
Leffingwell, D., SAFe Reference Guide (Scaled Agile Inc., current edition for SAFe 6.0) · scaledagileframework.com
Larman, C., and Vodde, B., Large-Scale Scrum: More with LeSS (Addison-Wesley, 2017) · Larman and Vodde, Practices for Scaling Lean & Agile Development (Addison-Wesley, 2008) · less.works
Sutherland, J., and Sutherland, J. J., Scrum: The Art of Doing Twice the Work in Half the Time (Random House, 2014) · The Scrum@Scale Guide v3.0 (Scrum Inc., 2022) · scrumatscale.com
Kniberg, H., and Ivarsson, A., “Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds” (Spotify white paper, 2012) · Kniberg, H., “Spotify Engineering Culture” Part 1 and Part 2 (Spotify Labs videos, 2014) · Sundén, J., “There is no Spotify Model” (2017)
Ambler, S., and Lines, M., Choose Your WoW! (Project Management Institute, current edition) · Ambler and Lines, Disciplined Agile Delivery (IBM Press, 2012) · pmi.org/disciplined-agile
Schwaber, K., and Scrum.org, The Nexus Guide · scrum.org/resources/nexus-guide
Anderson, D. J., and Bozheva, T., Kanban Maturity Model (Lean Kanban Inc., 2018) · Anderson, D. J., Kanban: Successful Evolutionary Change for Your Technology Business (Blue Hole Press, 2010) · kanbanmaturitymodel.com
Quartel, R., The FAST Guide · fastagile.io
Beck, K. et al., The Agile Manifesto (2001) · agilemanifesto.org
Primärquellen — Firmen-Capability-Seiten (Snapshot-Datum 2026-05-14)
BCG
BCG.com Agile at Scale capability pages · BCG “Agile Performance Management” publications · BCG X — the technology build unit — capability pages · BCG ING Bank transformation case-study coverage. Spezifische URLs werden im Snapshot fixiert.
McKinsey & Company
Bazigos, M., De Smet, A., and Gagnon, C., “The five trademarks of agile organizations” (McKinsey & Company, 2018) · McKinsey Quarterly agile articles (Aghina, De Smet et al., multiple years) · McKinsey ING Bank case studies · McKinsey Organizational Health Index publications. Spezifische URLs werden im Snapshot fixiert.
Deloitte
Deloitte.com Agile@Scale capability pages · Scaled Agile Inc. Global Transformation Partner directory entry · Deloitte Insights agile and transformation publications · Deloitte regional Agile Maturity Model articles. Spezifische URLs werden im Snapshot fixiert.
EY (und EY-Parthenon)
EY.com Business Agility capability pages · EY Transformation Realized framework pages · EY Wavespace publications · EY-Parthenon strategy and transformation insights. Spezifische URLs werden im Snapshot fixiert.
PwC
PwC.com Business Transformation and Digital Transformation capability pages · PwC BXT (Business-Experience-Technology) methodology publications · PwC Global CEO Survey (agile and transformation findings). Spezifische URLs werden im Snapshot fixiert.
KPMG
KPMG.com agile-transformation and Connected Enterprise capability pages · KPMG Powered Enterprise publications · KPMG Lakehouse programme overview · KPMG global advisory transformation insights. Spezifische URLs werden im Snapshot fixiert.
Accenture
Accenture.com Business Agility and Agile Engineering Studios capability pages · Accenture myConcerto industry-solutions pages · Accenture ADM and ADMnext publications · Scaled Agile Inc. Global Transformation Partner directory entry · Accenture-NVIDIA Business Group announcements. Spezifische URLs werden im Snapshot fixiert.
Bain & Company
Bain.com Agile Innovation capability pages · Rigby, D., Sutherland, J., and Takeuchi, H., Doing Agile Right: Transformation Without Chaos (Harvard Business Review Press, 2020) · Rigby et al., “Embracing Agile” (HBR, 2016), “Agile at Scale” (HBR, 2018), “The Agile C-Suite” (HBR, 2020) · Bain Technology Report (annual). Spezifische URLs werden im Snapshot fixiert.
Capgemini
Capgemini.com ADMnext capability pages · Capgemini agile and DevOps services pages · Capgemini Agile Innovation Center pages · Scaled Agile Inc. Global Transformation Partner directory entry · Capgemini Research Institute (CRI) publications. Spezifische URLs werden im Snapshot fixiert.
IBM Consulting
ibm.com/garage capability pages · IBM Garage Method playbook · IBM Enterprise Design Thinking pages · IBM Consulting Advantage publications · IBM American Airlines, USAA and other Garage case-study materials. Spezifische URLs werden im Snapshot fixiert.
Drittanbieter-Benchmarks und Community
Scaled Agile Inc. partner directory and enterprise adoption data · State of Agile Report (digital.ai, annual editions) · Scrum.org community statistics and adoption data · LeSS Company case-study library · Kanban University community materials. Spezifische URLs werden im Snapshot fixiert.
Für diese Ausgabe geführte Praktiker-Interviews
Wird während der Recherche ergänzt: benannte Gespräche mit Framework-Autoren und Senior-Firmen-Praktikern, sofern sie einer Zuschreibung zustimmen. Referenzwerke gewinnen materiell durch ein oder zwei zitierfähige Aussagen; die Kontaktaufnahme läuft zum Snapshot-Datum.
So zitieren Sie diesen Beitrag
APA-Stil:
Huber, B. (2026). The big consulting agile frameworks, compared: SAFe, LeSS, Scrum@Scale, Spotify, DAD, Nexus, KMM, FAST and how BCG, McKinsey, Deloitte, EY, PwC, KPMG, Accenture, Bain, Capgemini and IBM package them (2026 edition). Consulting Huber. https://consulting-huber.com/de/agile-consulting-frameworks-compared.html
BibTeX:
@article{huber2026agile,
author = {Huber, Bernhard},
title = {The Big Consulting Agile Frameworks, Compared (2026 edition)},
journal = {Consulting Huber},
year = {2026},
url = {https://consulting-huber.com/de/agile-consulting-frameworks-compared.html}
}
Snapshot-Datum: 14.05.2026. Jährliche Aktualisierung geplant; spätere Ausgaben bewahren die vorherige Ausgabe unter einer datierten URL.
Siehe auch: Business Agility Service · KI-Frameworks-Vergleich (Begleitbeitrag) · KI-Wertschöpfungs-Playbook · Fallstudien · Alle Leistungen