Duże frameworki agile w doradztwie, porównane: SAFe, LeSS, Scrum@Scale, Spotify, DAD, Nexus, KMM, FAST — i jak BCG, McKinsey, Deloitte, EY, PwC, KPMG, Accenture, Bain, Capgemini i IBM je pakują (edycja 2026)
Praktyczny przewodnik: co osiem frameworków scaled agile faktycznie przepisuje, co dziesięć dużych firm doradczych dokłada od siebie, i jak kupujący powinien czytać tę różnicę — ze źródłami pierwotnymi i nazwanymi flagowymi case'ami w każdym rozdziale.
Po co w ogóle porównywać?
„SAFe versus LeSS" jest wpisywane w Google milion razy. „Spotify model alternatives" — kolejne pół miliona. Za tymi zapytaniami niemal nigdy nie stoi transformation officer robiący przegląd literatury porównawczej. Stoi za nimi CEO, CIO albo członek rady nadzorczej, który przed spotkaniem w przyszłym tygodniu chce ustalić, co ich partner doradczy naprawdę zrobi w poniedziałek rano — i czy agile'owy wariant w ofercie to realna metoda, realny inżynieryjny fundament, czy przeklejenie tego samego slajdu o plemionach ze Spotify, który wygrał trzy ostatnie przetargi.
Uczciwą odpowiedź trudniej znaleźć, niż powinno być. Większość publicznych porównań frameworków piszą sami dostawcy metod — Scaled Agile Inc. o SAFe, LeSS Company o LeSS, Scrum Inc. o Scrum@Scale — i każdy z nich wygrywa argument, który sam napisał. Firmy doradcze publikują thought leadership o własnych ofertach, nie przyznając, jaką bazową metodę na nią nałożyły, której cicho unikają, albo która wygenerowała zaangażowanie od tego czasu wycofane. Kupujący zostaje sam z triangulacją, zwykle pod presją czasu, między stroną metody, która chce przychodu z certyfikacji, a stroną firmy, która chce kontraktu.
Ten tekst to praktyczny przewodnik z perspektywy kupującego. Rama jest taka: w 2026 roku warto znać osiem frameworków scaled agile i dziesięć firm doradczych, które sprzedają transformacje agile na skalę. Każdy framework to realny produkt z realnym autorem, realną teorią skalowania i realnym poglądem na praktykę inżynieryjną. Każda firma opakowuje jeden lub więcej z tych frameworków własnym markowanym IP, stosem certyfikacji i flagowym case'em. Interesujące pytania to te, na które firmy i dostawcy metod najmniej chętnie odpowiadają sami: gdzie opakowanie dodaje realną metodę, gdzie dodaje tylko markę, gdzie nazwany flagowy case wygląda tak samo pięć lat później, i gdzie założenia inżynieryjne frameworka wciąż się trzymają, gdy uwzględnić rozmiary zespołów z ery AI.
Mamy własne zdanie i powiemy je od razu, żeby reszta tekstu była uczciwa. Agile nie jest produktem. Agile to warstwa dostarczania pod każdym programem AI, cyfrowym i operacyjnym, który musi dalej dowozić po ceremonii uruchomienia. Framework, który robi to najlepiej dla danej organizacji, rzadko jest tym z największym ekosystemem certyfikacji albo najgłośniejszą marką. Zwykle jest to ten, którego założenia inżynieryjne, kształt governance i optymalny rozmiar zespołu pasują do pracy stojącej przed kupującym w danym kwartale. Wybranie go źle to najdroższy błąd w budżetach transformacyjnych — i ten, który w postmortemie przypisuje się „kulturze".
Poniższa struktura pozwala CEO przeczytać całość w piętnaście minut, a transformation officerowi użyć jej jako roboczego przewodnika. Sekcja 3 umieszcza osiem frameworków na osi czasu, która je wyprodukowała, bo bez tej historii żadna z tych prac nie ma sensu. Sekcje 4 i 5 porównują frameworki i firmy obok siebie. Sekcja 6 to tabela do zrzutu ekranu. Sekcje 7 i 8 mówią, co jest naprawdę inne, a co jest dekoracją. Sekcja 10 daje drzewo decyzyjne z perspektywy kupującego. Sekcja 11 mówi, gdzie pasujemy my.
Uwaga metodologiczna
Data snapshotu dla tego porównania to 14 maja 2026. Przewodniki po frameworkach, strony produktowe firm i biblioteki case studies się zmieniają; wszystko poniżej odzwierciedla stan publiczny na tę datę. Kolejne edycje zachowają poprzednią pod datowanym URL-em, aby każdy cytujący ten tekst mógł przypiąć wersję, do której się odwołuje.
Źródła pierwotne dla ośmiu frameworków. Tam, gdzie framework ma kanoniczną książkę, książka jest źródłem pierwotnym. SAFe: Dean Leffingwell, SAFe Reference Guide (Scaled Agile Inc., aktualna edycja dla SAFe 6.0). LeSS: Craig Larman i Bas Vodde, Large-Scale Scrum: More with LeSS (Addison-Wesley, 2017), plus ich wcześniejsza 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 i Sutherland, 2014). Spotify Model: Henrik Kniberg i Anders Ivarsson, “Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds” (2012), plus filmy Spotify Engineering Culture (Kniberg, 2014) i późniejsze retrospektywy Joakima Sundéna i Marcina Floryana. Disciplined Agile: Scott Ambler i Mark Lines, Choose Your WoW! (PMI, aktualna edycja). Nexus: Ken Schwaber i Scrum.org, The Nexus Guide. Kanban Maturity Model: David J. Anderson i Teodora Bozheva, Kanban Maturity Model (Lean Kanban Inc., 2018). FAST: Ron Quartel, The FAST Guide, plus wystąpienia społeczności.
Źródła pierwotne dla dziesięciu firm. Każda firma jest źródłowana z własnych opublikowanych stron produktowych, white paperów i komunikatów prasowych na datę snapshotu, plus — tam, gdzie istnieją — publicznie nazwane flagowe case studies. Tam, gdzie firma jest SAFe Global Transformation Partner, publiczny katalog partnerów jest traktowany jako niezależne źródło potwierdzające. Dane o adopcji w skali branży pochodzą z rocznego raportu State of Agile (digital.ai) i statystyk społeczności Scrum.org. Unikamy cytowania wewnętrznych wywiadów firmowych; wszystko poniżej ma źródło publiczne.
Co jest w zakresie, a co nie. W zakresie: frameworki z nazwanym autorem, opublikowaną metodyką i aktywną społecznością praktyków na poziomie zespołu zespołów lub wyżej. W zakresie: firmy publikujące markowaną ofertę transformacji agile, z realną ławką certyfikowanych lub wyspecjalizowanych konsultantów. Poza zakresem: czyste frameworki na poziomie zespołu (Scrum, Extreme Programming, jednozespołowy Kanban — to wejścia do frameworków skalowanych, nie ich konkurenci). Poza zakresem: certyfikacje agile coachingu bez metodyki dostarczania pod spodem. Poza zakresem: butikowe firmy doradcze poniżej pięćdziesięciu konsultantów — pytanie kupującego, któremu służy ten tekst, dotyczy firm zdolnych zmobilizować program klasy enterprise.
Dlaczego osiem frameworków, a nie sześć albo dwanaście. Sześć zaniża pole: pominięcie Kanban Maturity Model i FAST usunęłoby dwa frameworki, które jawnie nie wymagają reorganizacji struktury zespołowej — a to dokładnie sytuacja wielu organizacji poakwizycyjnych albo ograniczonych politycznie. Dwanaście zawyża pole: większość dodatkowych frameworków (Nexus+, Disciplined Agile Enterprise, indywidualne opakowania firmowe) to rozszerzenia lub rebrandy ośmiu opisanych tutaj. Osiem w tym tekście ma albo nazwanego autora z opublikowaną metodą i aktywną społecznością, albo jest jedynym markowanym assetem, jaki duża firma publikuje pod własnym nazwiskiem.
Krótka historia scaled agile (2001-2026)
Żaden z frameworków w tym porównaniu nie ma sensu bez historii. Scaled agile to dwudziestopięcioletni spór o to, jak dostarczać oprogramowanie w skali i tempie, których autorzy pierwotnego Agile Manifesto nigdy nie próbowali obsłużyć, a niemal każdy spór w dzisiejszej literaturze da się sprowadzić do tego, który rok, który problem i która kultura inżynieryjna wyprodukowały framework, który go broni.
2001 — Agile Manifesto. Siedemnastu praktyków spotyka się w Snowbird w Utah i publikuje cztery wartości i dwanaście zasad. Każdy framework w tym tekście jest w jakiejś formie ich spadkobiercą. Kluczowe jest to, że Manifest milczy na temat koordynacji między więcej niż jednym zespołem. To milczenie jest luką, którą wypełnia reszta tej historii.
1994-1999 — prehistoria. DSDM (Dynamic Systems Development Method) zostaje opublikowany w 1994 roku w Wielkiej Brytanii, z jawną narracją skalowania dla dostarczania w stałym budżecie. FDD (Feature-Driven Development) pojawia się w 1997 roku z pracy Jeffa De Luki w Singapurze. RUP (Rational Unified Process) zostaje sfinalizowany w Rational Software w 1998 roku i przejęty przez IBM w 2003 roku, dając dużym przedsiębiorstwom ciężki proces iteracyjny, który mogły kupić. Żaden z nich nie jest „agile" w definicji z 2001 roku, ale wszystkie dowodzą, że ten sam problem — skoordynowane dostarczanie wielozespołowe i wielofazowe — był już rozwiązywany, zanim Manifest nazwał ten system wartości.
2007-2010 — Scrum skaluje się przypadkiem. Scrum (Schwaber i Sutherland, sformalizowany w latach 90., spopularyzowany po Manifeście) staje się dominującą metodą na poziomie zespołu. Większe organizacje go adoptują, trafiają na granicę pojedynczego zespołu Scrum i zaczynają wymyślać lokalne rozwiązania. Wzorzec „Scrum of Scrums" jest udokumentowany, ale nierządzony. Pierwsze opublikowane próby świadomego skalowania pojawiają się w tym okresie — Practices for Scaling Lean & Agile Development (2008) Craiga Larmana i Basa Vodde to najwcześniejsze poważne opracowanie w formie książki.
2011 — SAFe 1.0. Dean Leffingwell publikuje pierwszy Scaled Agile Framework. To pierwszy framework scaled agile, który wygląda jak produkt do kupienia: numerowane role, nazwane ceremonie (najsłynniejsza to PI Planning), warstwa portfolio nad warstwą programu i stos certyfikacji. Transformation officerowie w przedsiębiorstwach, którzy do tej pory zmagali się z przełożeniem Scrum na poziomie zespołu na governance na poziomie programu, w końcu dostają coś, co mogą pokazać na slajdzie. W tym samym roku powstaje Scaled Agile Inc. Od tego momentu każdy inny framework w tym polu definiuje się częściowo przez to, w czym zgadza się z SAFe, a w czym je odrzuca.
2012-2014 — Spotify i LeSS. Henrik Kniberg i Anders Ivarsson publikują „Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds" w 2012 roku. To white paper, nie framework. Słownictwo — tribes, squads, chapters, guilds — rozprzestrzenia się szybciej niż jakikolwiek framework przed nim czy po nim. W 2014 roku Kniberg wypuszcza filmy Spotify Engineering Culture. W tym samym roku Larman i Vodde publicznie uruchamiają framework LeSS na less.works, pozycjonując go wprost jako „Scrum z regułami potrzebnymi, żeby go skalować" — świadomą kontrpozycję wobec gęstości ról i ceremonii w SAFe.
2014-2015 — Scrum@Scale i Disciplined Agile. Jeff Sutherland publikuje Scrum@Scale, zachowując oryginalny minimalizm Scrum w rdzeniu i dodając dwa cykle koordynacji (cykl Scrum Mastera i cykl Product Ownera). Scott Ambler i Mark Lines, pierwotnie w IBM, publikują Disciplined Agile Delivery jako alternatywę w stylu toolkitu, wspierającą cykle życia plan-driven, agile i lean w tym samym programie — świadome dostosowanie do przedsiębiorstw, które nie mogą przyjąć jednej filozofii dostarczania.
2015-2016 — Nexus. Ken Schwaber i Scrum.org uruchamiają Nexus jako opcję „Scrum, tylko trochę większy": egzoszkielet dla trzech do dziewięciu zespołów Scrum dzielących jeden produkt, z Nexus Integration Team odpowiedzialnym za integrację między zespołami. Niższy ślad marki niż SAFe czy LeSS, ale czystsze rozwiązanie dla zespołów już zaangażowanych w ekosystem Scrum.org.
2018 — Kanban Maturity Model i pięć znamion. David J. Anderson i Teodora Bozheva publikują Kanban Maturity Model, formalizując katalog praktyk ułożony w etapach dojrzałości, który nie wymaga zmian struktury zespołowej — pierwszy framework jawnie zaprojektowany dla organizacji, które nie mogą lub nie chcą się reorganizować. W tym samym roku McKinsey publikuje „The five trademarks of agile organizations" (Bazigos, De Smet, Gagnon), dając firmom doradczym diagnostykę niebędącą frameworkiem, którą mogą sprzedawać na poziomie rady nadzorczej.
2017-2019 — FAST i przejęcie DAD przez PMI. Ron Quartel publikuje framework FAST w 2017 roku — najbardziej radykalnie elastyczny z całego zestawu, z dynamicznym formowaniem zespołów i bez Scrum Masterów. W 2019 roku PMI przejmuje Disciplined Agile, dając frameworkowi wiarygodność enterprise i w mniej więcej równym stopniu spowalniając tempo jego otwartej społeczności.
2019-2022 — konsolidacja SAFe, retrospektywy Spotify. SAFe wygrywa argument regulowanych branż niemal domyślnie: to jedyny framework z audytowo przyjaznymi nazwanymi rolami, certyfikacją i ekosystemem partnerskim Scaled Agile Inc., który pozwala kupującemu ściągnąć wyspecjalizowanych konsultantów na zawołanie. Równolegle Joakim Sundén i inni z pierwotnego okresu Spotify publikują retrospektywy wyjaśniające, że „Spotify Model" zawsze był migawką, nigdy modelem — i że samo Spotify dawno wyewoluowało poza te diagramy.
2023-2026 — presja ery AI. AI generatywne kompresuje rozmiar zespołu. Zadania, które w 2018 roku wymagały plemienia osiemdziesięciu osób, mogą dziś dostarczyć osiem do piętnastu osób, wspierane platform engineeringiem i rozwojem wspomaganym AI. Platform engineering zastępuje część ceremonii koordynacyjnych wewnętrznymi platformami deweloperskimi. Frameworki pod presją strukturalną to te zbudowane dla programów o dużym headcouncie; frameworki cicho zdobywające grunt to te, które skalują się w dół bez strat (FAST, KMM, LeSS) albo przetrwają cięcie headcountu bez utraty tożsamości.
To jest kanon. Osiem frameworków porównanych w kolejnej sekcji to osiem, które przetrwały ten dwudziestopięcioletni spór z opublikowaną metodą, nazwanym autorem i aktywną społecznością w 2026 roku. Wszystko inne to albo metoda na poziomie zespołu (poza zakresem), albo opakowanie dostawcy na jednym z tych ośmiu (Sekcja 5), albo pomysł, który nie przetrwał zderzenia z budżetami enterprise.
Osiem frameworków, osiem ujęć
Każda metoda to osobny produkt, z własnym autorem, własnymi założeniami o skali i własną teorią o tym, gdzie mieści się praktyka inżynierii oprogramowania. Kolejność poniżej odpowiada mniej więcej wadze adopcji w zaangażowaniach doradczych klasy enterprise, nie jakości.
Zanim przejdziemy do ujęć — pochodzenie, bo większość pozornej różnorodności znika, gdy zobaczysz, skąd bierze się każda metoda. Pięć z ośmiu to rozszerzenia Scrum, jedna wywodzi się z Kanban Method, a dwie mają niezależne korzenie. To rodowód jest najbardziej przydatną rzeczą do zapamiętania w trakcie lektury reszty tej sekcji: kiedy framework wygląda nieznajomo, pytanie „co skaluje i z jakiej tradycji?" zwykle wyjaśnia jego kształt.
1. SAFe — Scaled Agile Framework
Autor / pochodzenie: Dean Leffingwell, pierwsze publiczne wydanie w 2011 roku, SAFe 6.0 aktualne od 2023 roku. Własność i znak towarowy Scaled Agile Inc.
Założenie skali: Zbudowany wokół Agile Release Train (ART) liczącego 50-125 osób. Konfiguracje Large Solution i Portfolio rozszerzają koordynację na programy wielo-ARTowe liczące kilka tysięcy osób. Zaprojektowany top-down, żeby pasować do przedsiębiorstw, nie bottom-up od Scrum na poziomie zespołu.
Prescriptive czy elastyczny: Najbardziej prescriptive framework w tym porównaniu. Nazwane role (RTE, Product Manager, Solution Train Engineer, System Architect, Business Owner, Release Train Engineer, plus Scrum Master i Product Owner na poziomie zespołu). Nazwane kadencje (PI — Program Increment — zwykle 8-12 tygodni). Nazwane ceremonie (PI Planning, System Demo, Inspect & Adapt). Nazwane artefakty (Programme Backlog, Solution Backlog, Portfolio Kanban).
Model governance: Hierarchiczny — Portfolio → Large Solution → Essential (ART) → Team. Warstwa Portfolio Lean Budgeting ze Strategic Themes i Value Streams. Audytowo przyjazny: każdą rolę, ceremonię i decyzję da się prześledzić.
Głębia inżynierii oprogramowania: DevOps i Continuous Delivery Pipeline to nazwane, główne filary. Built-In Quality, Test-First i leżące u podstaw praktyki XP są wprost przywoływane. W praktyce głębia inżynieryjna zależy niemal wyłącznie od SPC (SAFe Programme Consultant) prowadzącego wdrożenie; adopcja ceremonii zwykle wyprzedza adopcję inżynierską.
Gdzie błyszczy: Regulowane branże (banki, farmacja, obronność), które potrzebują governance możliwego do audytu. Duże przedsiębiorstwa z dojrzałymi biurami zarządzania programami, które już myślą w kategoriach ról i ceremonii. Konteksty dostarczania wielodostawcowego, gdzie wspólna kadencja i nazwane role koordynacyjne zmniejszają ryzyko integracji.
Gdzie jest źle stosowany: Małe organizacje przyjmujące pełny framework, bo ścieżka certyfikacyjna uczyniła go widocznym. Teatr PI Planning — dwudniowa ceremonia przyjęta jako rytuał bez leżącej pod spodem praktyki inżynieryjnej, która czyni kolejne dwanaście tygodni dowożalnymi. Portfolio Kanban jako artefakt uzasadniania budżetu, nie narzędzie flow. Każde wdrożenie, w którym SPC nigdy nie napisał kodu produkcyjnego.
Ocena vibe: Framework, który się przeskalował, bo przetrwał kontrolę enterprise. Uwielbiany przez transformation officerów, bo każda rozmowa, którą muszą przeprowadzić z radą nadzorczą, ma za sobą nazwany artefakt SAFe. Podejrzewany przez starszych inżynierów, bo ta sama rozmowa rzadko łączy się z pipeline'em CI. Najczęstsza luka między diagramem SAFe na ścianie a praktyką inżynieryjną w IDE.
Źródła: Leffingwell, SAFe Reference Guide (Scaled Agile Inc.) · scaledagileframework.com · katalog partnerów Scaled Agile Inc. · State of Agile Report (digital.ai, coroczny)
2. LeSS — Large-Scale Scrum
Autor / pochodzenie: Craig Larman i Bas Vodde, rozwinięty z ich pracy w Nokia Siemens Networks w połowie lat 2000. Pierwsza książka Practices for Scaling Lean & Agile Development (2008); framework LeSS sformalizowany na less.works w 2014 roku; Large-Scale Scrum: More with LeSS (2017) jest tekstem kanonicznym.
Założenie skali: Jeden produkt, jeden Product Owner, jeden Product Backlog. Właściwy LeSS obejmuje 2-8 zespołów. LeSS Huge obejmuje 8+ zespołów, zorganizowanych w Requirement Areas, każdy z Area Product Ownerem. Założenie jednego produktu to centralne zobowiązanie frameworka i jego najtrudniejsze do spełnienia ograniczenie.
Prescriptive czy elastyczny: Minimalistyczny z założenia. Slogan brzmi „Scrum zastosowany do wielu zespołów pracujących razem nad jednym produktem", z tylko tyloma dodatkowymi regułami, ile potrzeba, żeby to zadziałało — nie równoległa warstwa programu. Mniej nazwanych ról, mniej nazwanych wydarzeń, brak nakładki portfolio.
Model governance: Świadomie płaski. Jeden Product Owner dla wszystkich zespołów (albo jeden Area PO na Requirement Area w LeSS Huge). Brak osobnej warstwy programu. Brak odpowiednika Release Train Engineera. Koordynacja między zespołami odbywa się przez Multi-Team PBR, Overall Retrospective i wzorce component-mentor / travelling-engineer, nie przez rolę hierarchiczną.
Głębia inżynierii oprogramowania: Jedna z najwyższych spośród ośmiu. Continuous Integration jest nienegocjowalne. Framework wprost wymaga doskonałości technicznej: refaktoryzacja, proste projektowanie, test-driven development i współdzielona własność kodu są traktowane jako warunki wstępne, nie aspiracje. Larman i Vodde obszernie pisali o praktykach inżynieryjnych, które LeSS zakłada.
Gdzie błyszczy: Organizacje jednoproduktowe z kulturą inżynieryjną już skłonną do spłaszczania hierarchii. Firmy softwareowe, zespoły platformowe wewnątrz większych przedsiębiorstw, organizacje gotowe zdemontować silosy zespołów komponentowych i funkcjonalnych na rzecz zespołów feature'owych.
Gdzie jest źle stosowany: Portfolia wieloproduktowe próbujące wymusić założenie jednego PO. Regulowane branże, gdzie audyt oczekuje nazwanych ról compliance, których LeSS nie dostarcza. Organizacje przyjmujące strukturę, ale pomijające warunki wstępne inżynieryjne — LeSS bez continuous integration to po prostu Scrum z dodatkowymi retro.
Ocena vibe: Framework szanowany przez inżynierów. Framework, który transformation officerowie mają najtrudniej sprzedać radzie nadzorczej, bo oferuje mniej rozpoznawalnych markowo artefaktów niż SAFe. Ten, który daje najlepsze rezultaty w rękach silnego przywództwa technicznego, i najgorsze, gdy narzucony organizacji, która nie zapracowała jeszcze na dyscyplinę inżynieryjną, jaką zakłada.
Źródła: Larman i Vodde, Large-Scale Scrum: More with LeSS (Addison-Wesley, 2017) · less.works · certyfikacja LeSS Company (CLP, CLT) · Larman i Vodde, Practices for Scaling Lean & Agile Development (2008)
3. Scrum@Scale
Autor / pochodzenie: Jeff Sutherland (współtwórca Scrum razem z Kenem Schwaberem), założyciel Scrum Inc. Opublikowany w 2014 roku, aktualna wersja Scrum@Scale Guide 3.0 (2022). Zbudowany na bazie Scrum Guide, którego Sutherland i Schwaber są współautorami.
Założenie skali: Modularne i rekurencyjne. Pięć zespołów tworzy Scrum of Scrums (SoS); pięć SoS tworzy Scrum of Scrums of Scrums; i tak dalej. Brak twardego limitu liczby zespołów. Executive MetaScrum siedzi na szczycie jako strategiczne forum ustalania priorytetów. Framework jest zbudowany, żeby skalować się przez powtarzanie tego samego wzorca na wyższych poziomach, a nie przez wprowadzanie nowych warstw z nowymi rolami na każdym poziomie.
Prescriptive czy elastyczny: Minimalny rdzeń, modularna akrecja. Jedyne wymagane role to standardowe role Scrum (Scrum Master, Product Owner, Developer). Wszystkie dodatkowe komponenty — SoS, SoSoS, Executive Action Team, Executive MetaScrum — są dodawane tylko wtedy, gdy organizacja ich potrzebuje. Bliżej mu do meta-frameworka niż do jednej narzuconej implementacji.
Model governance: Dwa równoległe cykle. Cykl Scrum Mastera zajmuje się „jak" — usuwaniem przeszkód, ciągłym doskonaleniem, koordynacją między zespołami. Cykl Product Ownera zajmuje się „co" — priorytetyzacją backlogu, wizją strategiczną, feedbackiem klienta. Każdy cykl ma własną kadencję spotkań i właściciela odpowiedzialności.
Głębia inżynierii oprogramowania: Lekkie wytyczne wprost w samym frameworku. Książki Sutherlanda i szkolenia Scrum Inc. niosą mocną treść dotyczącą praktyk inżynieryjnych, ale przewodnik frameworka nie narzuca konkretnych praktyk. W praktyce oznacza to, że głębia inżynieryjna zależy od trenera lub konsultanta certyfikowanego przez Scrum Inc., prowadzącego wdrożenie.
Gdzie błyszczy: Organizacje już efektywnie prowadzące Scrum na poziomie zespołu, potrzebujące koordynacji na poziomie wielozespołowym bez dziedziczenia nakładki klasy SAFe. Firmy technologiczne z mid-marketu. Organizacje prowadzone przez inżynierię, które chcą zachować swoją istniejącą kulturę Scrum przez cały proces skalowania.
Gdzie jest źle stosowany: Organizacje mylące minimalizm z niejednoznacznością, porzucające framework, zanim modularne komponenty się ułożą. Programy transformacyjne oczekujące narzucenia, dla których opcjonalność Scrum@Scale jest niepokojąca. Wdrożenia przyjmujące wzorzec SoS bez odpowiadającego mu cyklu Product Ownera, generujące narzut koordynacyjny bez strategicznego dopasowania.
Ocena vibe: Nazwisko Sutherlanda niesie ogromną wagę. Framework ma mniejszą otwartą społeczność niż SAFe czy LeSS, ale wysoką koncentrację konsultantów przeszkolonych przez Scrum Inc. w terenie. Framework najczęściej przywoływany, gdy organizacja mówi „chcemy przeskalować nasz Scrum na poziomie zespołu bez rebrandingu". Mniejszy ślad marki niż SAFe; czystsza struktura koncepcyjna niż LeSS Huge.
Źródła: scrumatscale.com · The Scrum@Scale Guide v3.0 (Scrum Inc., 2022) · Sutherland i Sutherland, Scrum: The Art of Doing Twice the Work in Half the Time (Random House, 2014) · certyfikacja Scrum Inc. (SSM, SPS)
4. Spotify Model
Autor / pochodzenie: Henrik Kniberg i Anders Ivarsson, „Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds" (2012). Kontynuacja: filmy Kniberga Spotify Engineering Culture (część 1 i 2, 2014). Nigdy nieopublikowany przez Spotify jako oficjalny framework; oryginalne materiały opisują, co Spotify robiło w tamtym czasie, z wyraźnymi zastrzeżeniami, że model będzie dalej ewoluował. Późniejsze retrospektywy (Joakim Sundén 2017, Marcin Floryan i inni) wielokrotnie podkreślały, że samo Spotify odeszło od tych diagramów w ciągu roku lub dwóch.
Założenie skali: Squady typowo 6-12 osób, przekrojowe kompetencyjnie, autonomiczne. Tribes grupują powiązane squady, ograniczone (w Spotify) do około 100 osób, żeby zachować poczucie przynależności. Chapters przecinają tribes według dyscypliny (inżynieria, design, dane). Guilds to dobrowolne grupy zainteresowań obejmujące całą organizację.
Prescriptive czy elastyczny: Kulturowo prescriptive, strukturalnie sugestywny. Nakazy kulturowe — autonomia z dopasowaniem, zaufanie ponad kontrolę, „loosely coupled, tightly aligned" — są konkretne i wymagające. Elementy strukturalne (tribes, squads, chapters, guilds) opisują to, co robiło Spotify, nie są narzucone jako framework, który ktoś inny powinien przyjąć dosłownie.
Model governance: Macierzowy. Tribes są właścicielami wyników produktowych i roadmap. Chapters są właścicielami standardów dyscypliny i zarządzania ludźmi dla swoich członków. Guilds są właścicielami tematów przekrojowych według zainteresowań. Kluczowe jest to, że governance Spotify zakładało silną funkcję product management i silną platformę inżynieryjną — żadna z nich nie jest nazwana wprost na diagramach, obie są niezbędne w praktyce.
Głębia inżynierii oprogramowania: Domyślna, nie sprecyzowana. Model zakłada silną kulturę inżynieryjną: trunk-based development, continuous deployment, platformy wewnętrzne i wysoką poprzeczkę dla autonomii bez dryfu architektonicznego. Ci, którzy kopiują schemat organizacyjny bez platformy inżynieryjnej, dostają chaos koordynacyjny, nie autonomię.
Gdzie błyszczy: Organizacje natywnie technologiczne, prowadzone przez produkt, z istotną, już poczynioną inwestycją w platform engineering i developer experience. Organizacje, które już zapracowały na autonomię inżynieryjną, jaką model zakłada. Najbardziej użyteczne zastosowanie Spotify Model to często słownictwo dla organizacji, które już tak funkcjonują i potrzebują nazw dla tego, co robią.
Gdzie jest źle stosowany: Dominujący wzorzec porażki. Organizacje kopiują schemat organizacyjny — tribes, squads, chapters — bez kultury inżynieryjnej, funkcji product management czy inwestycji platformowej, które sprawiały, że struktura działała. Dostają diagram, nie rezultaty. Własne retrospektywy Spotify są jednoznaczne: model był migawką, migawka jest przestarzała, a traktowanie jej jako architektury docelowej to błąd.
Ocena vibe: Najbardziej wpływowy, najmniej wdrażalny artefakt w tym polu. Framework, który ludzie przywołują, mając na myśli „chcemy być bardziej jak Spotify" — co niemal zawsze znaczy, że przeczytali diagram, ale nie posty inżynieryjne. Użyteczny jako słownictwo, niebezpieczny jako szablon. Najczystszy sygnał, że organizacja przeczytała więcej niż diagram: odwołuje się do retrospektyw po 2017 roku, nie tylko do artykułu z 2012.
Źródła: Kniberg i 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 i inni, późniejsze retrospektywy Spotify
5. Disciplined Agile (DA / DAD)
Autor / pochodzenie: Scott Ambler i Mark Lines, pierwotnie rozwijany w IBM Rational od około 2009 roku. Opublikowany jako Disciplined Agile Delivery (DAD) w formie książki w 2012 roku, rozszerzony do szerszego toolkitu Disciplined Agile (DA) obejmującego zagadnienia na poziomie enterprise. Przejęty przez Project Management Institute (PMI) w 2019 roku, co dało PMI wiarygodny asset agile, a DA dystrybucję enterprise. Choose Your WoW! (Ambler i Lines, aktualna edycja pod PMI) jest tekstem kanonicznym.
Założenie skali: Toolkit, nie pojedynczy narzucony framework. DA wspiera cztery cykle życia w jednym programie: agile (oparty na Scrum), lean (ciągły przepływ), exploratory (lean-startup) i tradycyjny (plan-driven). Zespoły wybierają cykl życia pasujący do ich kontekstu, a toolkit prowadzi ten wybór diagramami celów.
Prescriptive czy elastyczny: Napędzany wyborem, zorientowany na cele. Zamiast narzucać konkretne praktyki, DA definiuje cele procesowe („Form Team", „Address Risk", „Coordinate Activities") i przedstawia opcje praktyk osiągania każdego celu z ich kompromisami. Framework jest świadomie agnostyczny co do tego, która praktyka jest właściwa, wymagając zamiast tego, żeby zespoły wybierały wprost.
Model governance: Pluralistyczny z założenia. Toolkit dopuszcza dostarczanie tradycyjne i agile w tym samym programie — świadome ustępstwo wobec przedsiębiorstw z regulowanymi strumieniami pracy, projektami zarządzanymi przez dostawców i czysto agile'owymi zespołami produktowymi działającymi obok siebie.
Głębia inżynierii oprogramowania: Szeroka, nie głęboka. Toolkit obejmuje DevOps, bezpieczeństwo, architekturę, zarządzanie danymi i operacje jako nazwane obszary celów. Kompromis polega na tym, że DA pokrywa więcej tematów niż jakikolwiek pojedynczy framework, ale mniej dogłębnie traktuje praktyki inżynieryjne w każdym z nich.
Gdzie błyszczy: Organizacje z mieszanymi kontekstami dostarczania — część zespołów potrzebuje dyscypliny plan-driven, inne prowadzą eksperymenty lean-startup, jeszcze inne dostarczają produkt na Scrum, wszystko pod jednym programem. Środowiska governance dopasowane do PMI, gdzie menedżerowie programów przeszkoleni w PMP potrzebują ścieżki do agile szanującej ich istniejące certyfikaty. Integracje poakwizycyjne, gdzie dwie kultury dostarczania muszą współistnieć bez podporządkowania jednej drugiej.
Gdzie jest źle stosowany: Małe organizacje przytłoczone szerokością toolkitu, którym lepiej służyłby pojedynczy narzucony framework. Organizacje, które widzą „PMI" na okładce i traktują DA jako „agile dla firm PMP", zamiast jako toolkit, którym naprawdę jest. Wdrożenia używające elastyczności DA jako przykrywki dla nigdy niepodjętego wyboru.
Ocena vibe: Niedoceniany w stosunku do swojego zakresu. Własność PMI dała frameworkowi wiarygodność enterprise, ale spowolniła tempo społeczności; konferencje są cichsze niż te SAFe czy LeSS, otwarte kontrybucje skromniejsze. Framework najbardziej prawdopodobny do wykonania realnej pracy w środowiskach regulowanych i portfeli mieszanych, i najmniej prawdopodobny jako odpowiedź, gdy organizacja mówi, że chce „przejść na agile".
Źródła: Ambler i Lines, Choose Your WoW! (PMI) · pmi.org/disciplined-agile · ścieżka certyfikacji PMI DA (DAC, DASM, DAVSC) · Ambler i Lines, Disciplined Agile Delivery (IBM Press, 2012)
6. Nexus
Autor / pochodzenie: Ken Schwaber (współtwórca Scrum) i Scrum.org. Nexus Framework został po raz pierwszy wydany w 2015 roku i dopracowywany w kolejnych aktualizacjach Nexus Guide, z aktualną wersją obejmującą ewoluującą praktykę Scrum.org. Zaprojektowany wprost jako minimalnie żywotne rozszerzenie Scrum na wiele zespołów na jednym produkcie.
Założenie skali: Od trzech do dziewięciu zespołów Scrum pracujących z jednego Product Backlogu nad jednym zintegrowanym inkrementem produktu. Powyżej dziewięciu zespołów autorzy frameworka zalecają albo przestrukturyzowanie na wiele instancji Nexus, albo rozważenie innego frameworka.
Prescriptive czy elastyczny: Wąski zakres, prescriptive w tym zakresie. Nexus dodaje tylko to, co ściśle potrzebne, żeby wielozespołowy Scrum działał: Nexus Integration Team (jednostka robocza, nie osobna hierarchia ról), wydarzenia na poziomie Nexus obejmujące wydarzenia Scrum na poziomie zespołu, i Nexus Sprint Goal, który spina inkrement. Nic innego się nie zmienia.
Model governance: Skoncentrowany na zespole integracji. Nexus Integration Team odpowiada za zintegrowany inkrement i za coachowanie zespołów Scrum w praktykach inżynieryjnych umożliwiających integrację. Zależności między zespołami są wydobywane i adresowane w Nexus Sprint Planning, nie pozostawiane doraźnej koordynacji.
Głębia inżynierii oprogramowania: Wprost dotyczy dyscypliny integracji. Definition of Done na poziomie Nexus wymusza praktyki inżynieryjne — continuous integration, testy integracyjne, wspólne narzędzia — które łatwo pominąć na poziomie zespołu. W praktyce to tutaj Nexus dostarcza swoją wartość: czyniąc dyscyplinę integracji wymogiem strukturalnym, nie aspiracją coachingową.
Gdzie błyszczy: Organizacje jednoproduktowe z trzema do dziewięciu zespołami, które już efektywnie praktykują Scrum i chcą minimalnej zmiany procesu potrzebnej do skalowania. Organizacje produktowe prowadzone przez inżynierię, zaangażowane w ekosystem Scrum.org. Wdrożenia preferujące jeden dobrze zintegrowany framework nad nakładką portfolio.
Gdzie jest źle stosowany: Organizacje na poziomie dziesięciu lub więcej zespołów, które przyjmują Nexus, bo już go prowadziły przy dziewięciu i nie potrafiły się przełączyć. Organizacje ze słabymi fundamentami Scrum na poziomie zespołu, gdzie Nexus po prostu przenosi istniejące dysfunkcje na wyższą warstwę koordynacji. Portfolia wieloproduktowe, których nie powinno się było wymuszać na jednym backlogu.
Ocena vibe: Opcja „Scrum, tylko trochę większy". Niższy ślad marki niż SAFe czy LeSS, z mniejszym ekosystemem zewnętrznych konsultantów. Najczystsza ścieżka dla organizacji już w strumieniu szkoleniowym Scrum.org, które chcą się skalować bez rebrandingu. Framework najczęściej zapominany w debatach o frameworkach, bo nie próbuje tej debaty wygrać — próbuje dalej być Scrum.
Źródła: Schwaber i Scrum.org, The Nexus Guide · scrum.org/resources/nexus-guide · certyfikacja Scrum.org Scaled Professional Scrum (SPS) · case studies społeczności Scrum.org
7. Kanban Maturity Model (KMM)
Autor / pochodzenie: David J. Anderson i Teodora Bozheva, Kanban Maturity Model (Lean Kanban Inc., 2018; kolejne rewizje). Anderson jest też autorem fundamentalnej książki Kanban (2010), która ustanowiła Kanban Method w dostarczaniu oprogramowania. Dystrybuowany przez Kanban University (dawniej Lean Kanban University) i Mauvius Group.
Założenie skali: Ma zastosowanie na poziomie zespołu, dostarczania usług i enterprise. Dojrzałość jest ułożona w etapach od 0 do 6 (siedem etapów: Oblivious, Emerging, Defined, Managed, Established, Optimising, Congruent), każdy poziom dodaje praktyki budujące na poprzednim. Model wprost nie wymaga reorganizacji struktury zespołowej, żeby zacząć — organizacja może przyjąć KMM bez demontażu istniejącego schematu organizacyjnego.
Prescriptive czy elastyczny: Katalog praktyk zorganizowany według poziomu dojrzałości, nie pojedynczy narzucony proces. Centralna przesłanka frameworka — „zacznij od tego, co robisz teraz; zgódź się dążyć do zmiany ewolucyjnej" — traktuje istniejącą organizację jako punkt startowy i pozwala, żeby adopcja praktyk podążała za zdolnościami.
Model governance: Oparty na flow i zorientowany na usługi. Praca jest traktowana jako strumień popytu wobec pojemności. Governance przesuwa się od myślenia projektowo-zasobowego w stronę dostarczania usług, klas usług i jawnych polityk obsługi różnych typów popytu. Brak wymaganych zmian ról — istniejąca struktura organizacyjna pozostaje na miejscu.
Głębia inżynierii oprogramowania: Agnostyczna. KMM koncentruje się na przepływie pracy, zarządzaniu popytem, klasach usług i politykach; nie ma zdania na temat konkretnych praktyk inżynieryjnych. Zespoły bogate inżyniersko zachowują swoje praktyki; zespoły z mniejszym zapleczem inżynieryjnym nie są do nich zmuszane przez framework.
Gdzie błyszczy: Organizacje mocno operacyjne i dostarczające usługi — operacje IT, zespoły infrastrukturalne, wsparcie, praca w procesach regulowanych. Organizacje, gdzie reorganizacja jest politycznie lub praktycznie niemożliwa. Dojrzałe firmy inżynieryjne, które już odrzuciły gęstość ceremonii Scrum i chcą poprawy strukturalnej bez utraty istniejącego flow.
Gdzie jest źle stosowany: Kupujący z organizacji produktowych oczekujący narzuceń dotyczących struktury zespołu, którzy uznają ewolucyjną postawę KMM za frustrującą. Wdrożenia sprowadzające framework do „powieś tablicę Kanban na ścianie" bez przyjęcia limitów WIP, klas usług czy progresji praktyk ułożonej w etapach dojrzałości. Organizacje przyjmujące KMM jako pretekst, żeby uniknąć trudniejszej pracy organizacyjnej.
Ocena vibe: Framework, po który sięgają konsultanci, gdy organizacja odrzuciła Scrum, ale wciąż potrzebuje poprawy strukturalnej. Cichy, trwały wzorzec adopcji: mniej flagowych case studies niż SAFe, niższy ślad marki, ale wysoka retencja po przyjęciu. Najmniej dyskutowany framework w tym porównaniu i jeden z najbardziej użytecznych we właściwym kontekście organizacyjnym.
Źródła: Anderson i Bozheva, Kanban Maturity Model (Lean Kanban Inc., 2018) · kanbanmaturitymodel.com · certyfikacja Kanban University (KMP, KCP) · Anderson, Kanban: Successful Evolutionary Change for Your Technology Business (Blue Hole Press, 2010)
8. FAST — Fluid Agile Scaling Technology
Autor / pochodzenie: Ron Quartel, pierwotnie sformułowany w 2017 roku na bazie jego wcześniejszej pracy z samoorganizującymi się zespołami agile w skali. Udokumentowany w FAST Guide, dopracowywany przez kolejne rewizje i kontrybucje społeczności na fastagile.io. Framework czerpie z zasad Open Space Technology dla samoorganizacji i stosuje je w kontekście dostarczania oprogramowania.
Założenie skali: „Plemię" typowo 30-150 osób. Kluczowe jest to, że zespoły nie są stałe. Na początku każdej krótkiej iteracji (typowo od dwóch dni do tygodnia) członkowie plemienia samoorganizują się wokół zadań, na których im zależy, tworzą zespoły na tę iterację i rozwiązują się na jej koniec. Stałe zespoły Scrum ze stabilnym składem nie istnieją.
Prescriptive czy elastyczny: Radykalnie elastyczny. Brak stałych Scrum Masterów. Brak stałych Product Ownerów. Brak stałych składów zespołów. Nakazy strukturalne są minimalne: spotkanie plemienia na początku każdego cyklu, marketplace, gdzie praca jest oferowana i podejmowana, oraz lekkie work streams utrzymujące ciągłość między cyklami dla dłużej trwających spraw.
Model governance: Samoorganizujący się i oparty na rynku. Popyt ujawnia się na spotkaniu plemienia; ludzie wybierają, nad czym pracować; stewardzi work streamów utrzymują ciągłość dla spraw rozciągniętych na wiele cykli. Model opiera się na zbiorowej odpowiedzialności i przejrzystej powierzchni, nie na nazwanym autorytecie opartym na roli.
Głębia inżynierii oprogramowania: Zakłada dojrzałą kulturę inżynieryjną. Brak wbudowanej kompensacji dla słabego fundamentu technicznego. Bez trunk-based development, continuous integration, obszernego pokrycia testami i współdzielonej własności kodu model płynnych zespołów produkuje chaos, nie autonomię. FAST nie wybacza skrótów inżynieryjnych w sposób, w jaki nie wybaczają ich bardziej ustrukturyzowane frameworki.
Gdzie błyszczy: Organizacje dojrzałe technologicznie, o wysokim zaufaniu, gotowe rozpuścić stałą tożsamość zespołu na rzecz płynnej współpracy. Grupy badawcze, zespoły platform engineering, zaawansowane organizacje produktowe, gdzie praca jest z natury zmienna. Organizacje, gdzie istniejąca kultura inżynieryjna jest wystarczająco silna, żeby wchłonąć utratę struktury na poziomie zespołu.
Gdzie jest źle stosowany: Organizacje bez dyscypliny inżynieryjnej, jaką zakłada FAST — bez continuous integration i silnej bazy testów codzienne przetasowania frameworka stają się codziennym gaszeniem pożarów. Organizacje z zewnętrznymi zobowiązaniami lub twardymi terminami dostarczania, które potrzebują przewidywalności zapewnianej przez stałe zespoły. Programy z regulacyjnymi wymogami nazwanej indywidualnej odpowiedzialności.
Ocena vibe: Outlier. Niemal nieznany kupującym korporacyjnym, sporadycznie przywoływany przez starszych inżynierów jako najbardziej autentycznie agile'owy spośród frameworków skalowanych. Framework najczęściej pojawiający się w rozmowie starszych inżynierów o tym, „co by naprawdę zadziałało, gdybyśmy nie musieli dopasować się do szablonu zamówień publicznych". Wpływowy daleko poza swoim śladem adopcji — pomysły z FAST pojawiają się w ścieżkach ewolucji innych frameworków.
Źródła: Quartel, The FAST Guide (fastagile.io) · fastagile.io · wystąpienia i case studies społeczności FAST · materiały źródłowe Open Space Technology (Owen, 1997)
Jak pakują je duże firmy
Dziesięć firm poniżej dostarcza transformacje agile na skalę. Każda ma nazwaną ofertę, historię opakowania i (najczęściej) nazwany flagowy case study. Wzorzec: metoda bazowa (zwykle SAFe, czasem LeSS albo inspirowana Spotify), plus firmowe sygnaturowe opakowania (nazwane platformy, akceleratory, szkolenia), plus dostęp do globalnego talentu. Różnice tkwią w opakowaniach.
BCG
Nazwana oferta: Agile at Scale, umiejscowiona pod praktykami People & Organization i Business Transformation. Sygnaturowa diagnostyka to „Agile Performance Management".
Warstwy metod: Struktury tribe i squad inspirowane Spotify tworzą dominujący wzorzec w opublikowanych case'ach agile BCG. Wzorce koordynacji SAFe pojawiają się w zaangażowaniach w regulowanych branżach. Własna nakładka governance portfolio BCG siedzi na dowolnej metodzie bazowej, jakiej używa dane zaangażowanie.
Sygnaturowe IP: BCG Agile Diagnostic, framework Agile Performance Management, seria benchmarków „Build for the Future". BCG X — połączona jednostka tech build powstała w 2022 roku z BCG GAMMA, BCG Platinion i BCG Digital Ventures — dostarcza inżynieryjną stronę dużych transformacji.
Nazwany flagowy case: Transformacja ING Bank z lat 2015-2018 „inspirowana Spotify" to najczęściej cytowany publiczny case agile BCG (opowiadany wspólnie z McKinsey, którego zaangażowanie jest również publicznie udokumentowane). Roche i kilka dużych europejskich banków pojawia się w bibliotece case studies BCG.
Szkolenia/certyfikacja: Wewnętrzne akademie BCG dla konsultantów. Brak publicznej ścieżki certyfikacji. BCG X prowadzi wewnętrznie szkolenia specyficzne dla inżynierii.
Vibe pozycjonowania: Strategia przede wszystkim. Agile jest pozycjonowany jako transformacja operating modelu należąca do poziomu C-suite, z praktyką inżynieryjną jako sprawą downstream obsługiwaną przez BCG X lub zespoły inżynieryjne klienta. Koncepcyjnie sąsiaduje z szerszą tezą BCG „10-20-70" z artykułu o AI — agile dostarcza 70 (ludzie, proces, change).
Źródła: strona produktowa agile-at-scale BCG.com, publikacje Agile Performance Management, relacje o case studies transformacji ING (BCG i strony trzecie). Konkretne URL-e do przypięcia podczas sesji researchu; strony firm odświeżają się często.
McKinsey & Company
Nazwana oferta: Transformacja agile pod praktyką People & Organizational Performance, zakotwiczona w diagnostyce „Five Trademarks of Agile Organizations". Sąsiadujące publikacje McKinsey Quarterly i McKinsey Insights służą jako publiczna warstwa IP.
Warstwy metod: Struktury inspirowane Spotify pojawiają się w opublikowanej pracy case'owej McKinsey. Koordynacja we wzorcu SAFe w zaangażowaniach w regulowanych branżach. Własna nakładka projektowania organizacyjnego McKinsey (Org Health Index, Influence Model) siedzi w poprzek pracy dostarczania agile.
Sygnaturowe IP: „The five trademarks of agile organizations" (Bazigos, De Smet, Gagnon, 2018) to dominujący opublikowany asset — pięć znamion to North Star ucieleśniona w całej organizacji, sieć uwłasnowolnionych zespołów, szybkie cykle decyzji i uczenia się, dynamiczny model ludzi oraz technologia nowej generacji umożliwiająca pracę. Eseje Agile Performance Management i diagnostyka agile Org Health Index dopełniają publiczne IP.
Nazwany flagowy case: Transformacja ING Bank z lat 2015-2018 (opowiadana publicznie wspólnie z BCG). Transformacja agile R&D Roche. Liczne transformacje bankowe w Azji i Europie cytowane w McKinsey Quarterly. Case ING autorstwa McKinsey to najczęściej cytowana transformacja agile w literaturze biznesowej.
Szkolenia/certyfikacja: Wewnętrzna sieć praktyków McKinsey. Brak publicznej ścieżki certyfikacji. Program szkoleniowy McKinsey Forward (szerszy rozwój przywództwa) zawiera treści agile.
Vibe pozycjonowania: Agile jako problem projektowania organizacyjnego. Nacisk na diagnostykę, ankiety i zmianę operating modelu, nie na praktykę inżynieryjną. Firma najbardziej prawdopodobna do poprowadzenia rozmowy o transformacji agile na poziomie rady nadzorczej i najmniej prawdopodobna do bycia w pokoju, gdy konfiguruje się pipeline CI.
Źródła: Bazigos, De Smet, Gagnon, „The five trademarks of agile organizations" (McKinsey, 2018) · teksty agile McKinsey Quarterly (Aghina, De Smet i inni, wiele lat) · case studies ING Bank McKinsey. Data snapshotu do przypięcia podczas researchu.
Deloitte
Nazwana oferta: Agile@Scale (przywoływane też jako „Agile at Scale" w różnych materiałach Deloitte), wsparte diagnostyką Agile Maturity Model i Agile Transformation Playbook.
Warstwy metod: SAFe jest dominującą metodą bazową — Deloitte jest Scaled Agile Inc. Global Transformation Partner na najwyższym poziomie ekosystemu partnerskiego. Struktury LeSS i inspirowane Spotify pojawiają się tam, gdzie pasuje kontekst, szczególnie w zaangażowaniach prowadzonych przez produkt. Scrum na poziomie zespołu wszędzie.
Sygnaturowe IP: Agile Maturity Model, Agile Transformation Playbook, akceleratory partnerstwa SAFe, strony produktowe Agile@Scale. Sąsiedztwo: framework Trustworthy AI (siedem wymiarów, z artykułu o AI) dzieli DNA governance z podejściem Deloitte do agile-governance.
Nazwany flagowy case: Transformacje sektora publicznego i usług finansowych w USA, Wielkiej Brytanii i Europie. Konkretne nazwane case'y różnią się w zależności od firmy członkowskiej Deloitte; flagowy case do potwierdzenia podczas snapshotu.
Szkolenia/certyfikacja: Jedna z największych ławek konsultantów certyfikowanych SAFe w branży. Wewnętrzna Deloitte Agile Academy. Partnerstwo PMI Disciplined Agile dla programów hybrydowych.
Vibe pozycjonowania: Zgodny z SAFe, przyjazny governance, gotowy na audyt. Firma do zatrudnienia, gdy regulatorzy są w pokoju, a transformacja musi przetrwać przegląd zgodności. Mniejsza głębia inżynierii produktowej niż Capgemini czy IBM; większa głębia governance programowego niż McKinsey czy Bain.
Źródła: strony produktowe Agile@Scale Deloitte.com · katalog Scaled Agile Inc. Global Transformation Partner · publikacje agile Deloitte Insights · regionalne opracowania Agile Maturity Model. Data snapshotu do przypięcia podczas researchu.
EY (i EY-Parthenon)
Nazwana oferta: Business Agility (przywoływane też jako „Agile Business Reinvention" w różnych materiałach EY), pozycjonowana w szerszym frameworku Transformation Realized.
Warstwy metod: Zgodne z SAFe w większości publicznych case'ów. Scrum na poziomie zespołu. Nakładka change-management „transformation activation" EY siedzi w poprzek dostarczania agile.
Sygnaturowe IP: Framework Transformation Realized (nadrzędna metodyka transformacyjna EY, w którą Business Agility wpina się jako model dostarczania). Studia facylitacyjne EY Wavespace do warsztatów i wydarzeń planistycznych w stylu PI. Sąsiedztwo: EY.ai i EYQ Agentic Platform (z artykułu o AI) — dostarczanie agile na szczycie stosu AI EY dla branż regulowanych.
Nazwany flagowy case: Transformacje w branżach regulowanych (usługi finansowe, administracja, podatki). Konkretne nazwane case'y różnią się w zależności od firmy członkowskiej EY i poufności zaangażowania; flagowy case do potwierdzenia podczas snapshotu.
Szkolenia/certyfikacja: Partner SAFe. Wewnętrzny program facylitacji EY Wavespace. Certyfikaty change-management specyficzne dla EY.
Vibe pozycjonowania: Mocno nastawiony na transformację i change. Agile żyje wewnątrz szerszej historii zmiany, nie stoi osobno. Mniejsza głębia inżynierii oprogramowania niż Capgemini czy IBM; większa głębia change-management i stakeholder-management niż większość peerów. Firma do zatrudnienia, gdy dostarczanie agile jest środkiem, a restrukturyzacja branży regulowanej celem.
Źródła: strony produktowe Business Agility i Transformation Realized EY.com · publikacje EY Wavespace · insighty strategiczno-transformacyjne EY-Parthenon. Data snapshotu do przypięcia podczas researchu.
PwC
Nazwana oferta: Transformacja agile pozycjonowana pod praktyką Business Transformation, często wiązana z zaangażowaniami Digital Transformation. Operating model PwC BXT (Business-Experience-Technology) stanowi nadrzędną architekturę transformacyjną.
Warstwy metod: SAFe i Scrum@Scale pojawiają się w opublikowanej pracy case'owej PwC. Scrum na poziomie zespołu. Model BXT opakowuje dowolną bazową metodę agile, jakiej używa zaangażowanie.
Sygnaturowe IP: Operating model BXT (najczęściej cytowane IP transformacyjne PwC — argumentuje, że Business, Experience i Technology muszą być projektowane i prowadzone razem, nie przekazywane sobie po kolei). Ocena Digital Fitness. Sąsiedztwo: ChatPwC, wdrożenie ChatGPT Enterprise na ~200 000 miejsc (z artykułu o AI), to najbardziej przeskalowane wewnętrzne narzędzie GenAI spośród wszystkich firm w tym porównaniu — zespoły dostarczające agile pracują w miejscu pracy nasyconym GenAI.
Nazwany flagowy case: Wdrożenia agile w usługach finansowych na rynkach USA, Wielkiej Brytanii i Europy. Flagowy case do potwierdzenia podczas snapshotu; publikacja case'ów agile PwC ma niższy wolumen niż u peerów z Big Four.
Szkolenia/certyfikacja: Ławka certyfikowana SAFe. Programy PwC Academy. Wewnętrzne szkolenie facylitatorów BXT.
Vibe pozycjonowania: Prowadzony przez change-management. Agile przedstawiany jako transformacja behawioralna enterprise, nie praktyka inżynierii oprogramowania. Mniej markowanej, specyficznej dla agile metodyki niż u Deloitte czy Accenture — praca agile PwC dzieje się wewnątrz Business Transformation, nie stoi jako osobna oferta.
Źródła: strony produktowe Business Transformation i Digital Transformation PwC.com · publikacje metodyki BXT · PwC Global CEO Survey (wnioski dotyczące agile). Data snapshotu do przypięcia podczas researchu.
KPMG
Nazwana oferta: Transformacja agile umiejscowiona w frameworku Connected Enterprise, często łączona z KPMG Powered Enterprise (metodyką transformacji przyspieszaną SaaS-em KPMG).
Warstwy metod: SAFe jest dominującą metodą bazową w opublikowanych zaangażowaniach agile KPMG. Scrum na poziomie zespołu. Connected Enterprise opakowuje dostarczanie agile oceną modelu zdolności KPMG.
Sygnaturowe IP: Connected Enterprise (osiem zdolności funkcjonalnych i klienckich ułożonych pod transformację end-to-end), Powered Enterprise (prekonfigurowane akceleratory rozwiązań SaaS dla ERP, HR, finansów i operacji), KPMG Lakehouse (flagowy kampus szkoleniowo-innowacyjny firmy). Sąsiedztwo: framework Trusted AI (10 filarów, z artykułu o AI) dzieli DNA governance z podejściem KPMG do agile-governance.
Nazwany flagowy case: Transformacje usług finansowych i sektora publicznego w Wielkiej Brytanii, USA i regionie Azji i Pacyfiku. Konkretny nazwany flagowy case do potwierdzenia podczas snapshotu.
Szkolenia/certyfikacja: Partner SAFe. KPMG Lakehouse (Orlando na Florydzie i inne kampusy) dostarcza immersyjne szkolenia zarówno konsultantom, jak i zespołom klienta.
Vibe pozycjonowania: Prowadzony przez model zdolności. Agile siedzi wewnątrz szerszego frameworka zdolności, nie stoi jako centralny punkt. DNA audytu KPMG przenosi się na projekt agile-governance — firma do zatrudnienia, gdy transformacja agile musi wyprodukować możliwe do prześledzenia, audytowalne artefakty governance. Sąsiedztwo „first claim" ISO/IEC 42001 (z artykułu o AI) wzmacnia postawę governance.
Źródła: strony produktowe agile-transformation i Connected Enterprise KPMG.com · publikacje KPMG Powered Enterprise · przegląd programu KPMG Lakehouse. Data snapshotu do przypięcia podczas researchu.
Accenture
Nazwana oferta: Business Agility w ramach praktyki Strategy & Consulting; Agile Engineering Studios w ramach praktyki Technology; usługi agile-i-DevOps w ramach Operations. Zdolność agile Accenture obejmuje trzy z czterech linii usługowych firmy.
Warstwy metod: SAFe jest dominującą metodą bazową, a Accenture jest jednym z największych SAFe Global Transformation Partners. Struktury inspirowane Spotify pojawiają się w zaangażowaniach natywnie technologicznych. Scrum na poziomie zespołu wszędzie. Nakładka rozwiązań branżowych myConcerto siedzi na szczycie dostarczania agile.
Sygnaturowe IP: myConcerto (akcelerator rozwiązań dopasowanych branżowo), Agile Engineering Studios (regionalne huby inżynieryjne), ADM i ADMnext (Application Development & Maintenance — nakładka dostarczania usług inżynieryjnych; ADMnext to zrebrandowana wersja nowej generacji). Sąsiedztwo: AI Refinery i inwestycja 3 mld USD w AI (z artykułu o AI) — zespoły agile dostarczają na Refinery; Accenture-NVIDIA Business Group to najbardziej markowany sojusz z hyperscalerem w doradztwie.
Nazwany flagowy case: Liczne transformacje z listy Fortune 500 cytowane publicznie w usługach finansowych, retailu, ochronie zdrowia i sektorze przemysłowym. Konkretny nazwany flagowy case do potwierdzenia podczas snapshotu; wolumen case studies Accenture jest jednym z najwyższych w branży.
Szkolenia/certyfikacja: Prawdopodobnie największa ławka konsultantów certyfikowanych SAFe spośród wszystkich firm (dziesiątki tysięcy certyfikatów w globalnej kadrze). Accenture Academy. Agile Engineering Studios jako silnik rozwoju ławki.
Vibe pozycjonowania: Skala i egzekucja. Agile siedzi wewnątrz szerszej oferty usług inżynieryjnych Accenture, nie jako samodzielna transformacja. Firma do zatrudnienia, gdy transformacja wymaga globalnego dostarczania, koordynacji wielodostawcowej i ławki certyfikowanej SAFe dostępnej na zawołanie. Mniej narracji prowadzonej przez senior-partnerów niż McKinsey czy Bain; większa głębia silnika egzekucji niż u jakiegokolwiek peera.
Źródła: strony produktowe Business Agility, Agile Engineering Studios i myConcerto Accenture.com · katalog Scaled Agile Global Transformation Partner · publikacje ADM i ADMnext · komunikaty Accenture-NVIDIA Business Group. Data snapshotu do przypięcia podczas researchu.
Bain & Company
Nazwana oferta: Agile Innovation (najbardziej charakterystyczna opublikowana oferta agile Bain), wsparta przez Bain Agile Innovation Network i diagnostykę Agile Enterprise na poziomie portfolio.
Warstwy metod: Scrum na poziomie zespołu. Własna diagnostyka Agile Enterprise Bain na poziomie portfolio. Mniej prescriptive frameworkowo niż Big Four; Bain pracuje na warstwie strategicznej i operating modelu, pozwalając wybranemu frameworkowi na poziomie zespołu dopasować się do zaangażowania.
Sygnaturowe IP: Darrell Rigby (partner Bain, obecnie na emeryturze, ale wciąż obecny jako thought leader) współautorował Doing Agile Right (Harvard Business Review Press, 2020) — najczęściej publikowany asset agile Bain. Wcześniejsze artykuły HBR to „Embracing Agile" (2016), „Agile at Scale" (2018) i „The Agile C-Suite" (2020). Sąsiedztwo: Sage (wewnętrzne narzędzie oparte na GPT-4, z artykułu o AI) i sojusz z OpenAI — zespoły agile dostarczają współprojektowaną pracę AI na szczycie markowanych assetów sojuszu.
Nazwany flagowy case: John Deere (agile w produkcji, obszernie cytowany przez Rigby'ego), Bosch (przemysłowa transformacja agile), plus liczne case'y w katalogu HBR Rigby'ego. Opublikowana baza case'ów jest niezwykle obszerna jak na firmę strategiczną.
Szkolenia/certyfikacja: Wewnętrzna Bain Agile Innovation Practice. Brak publicznej ścieżki certyfikacji. Książka Rigby'ego i artykuły HBR pełnią funkcję zewnętrznego transferu wiedzy Bain.
Vibe pozycjonowania: Agile jako dyscyplina innowacji, nie metoda dostarczania IT. Narracja prowadzona przez senior-partnerów. Firma najbardziej prawdopodobna do bycia w pokoju, gdy producent przemysłowy chce wprowadzić agile do rozwoju produktu bez restrukturyzacji dostarczania IT. Mniej ceremonii, więcej strategii.
Źródła: strony produktowe Agile Innovation Bain.com · Rigby, Sutherland i Takeuchi, Doing Agile Right (HBR Press, 2020) · Rigby i in., artykuły HBR 2016-2020 · Bain Technology Report (coroczny). Data snapshotu do przypięcia podczas researchu.
Capgemini
Nazwana oferta: ADMnext (Application Development & Maintenance, natywnie agile i DevOps — flagowa platforma usług inżynieryjnych Capgemini), wsparta usługami Agile i Scaled Agile oraz Capgemini Agile Innovation Centers.
Warstwy metod: SAFe jest dominującą metodą bazową — Capgemini jest Scaled Agile Global Transformation Partner. Scrum, Kanban i DevOps są zintegrowane, nie warstwowane osobno; praktyka inżynieryjna i praktyka agile przychodzą razem.
Sygnaturowe IP: Platforma ADMnext (najczęściej cytowany asset dostarczania usług inżynieryjnych w tym porównaniu), Capgemini Agile Innovation Centers (regionalne studia inżynieryjne). Sąsiedztwo: Resonance AI Framework (z artykułu o AI) siedzi na szczycie platformy inżynieryjnej; status Capgemini Google Cloud Partner of the Year 2025 wzmacnia nachylenie prowadzone przez inżynierię.
Nazwany flagowy case: Europejskie transformacje w bankowości, motoryzacji i energetyce. Powszechnie cytowane Mercedes-Benz, BNP Paribas i kilku dużych europejskich detalistów. Konkretny flagowy case do potwierdzenia podczas snapshotu; biblioteka case'ów Capgemini jest silnie skoncentrowana na Europie i merytorycznie prowadzona przez inżynierię.
Szkolenia/certyfikacja: Jedna z największych ławek certyfikowanych SAFe poza Accenture. Capgemini University (flagowy kampus szkoleniowy firmy, Francja). Wewnętrzna certyfikacja praktyków ADMnext.
Vibe pozycjonowania: Prowadzony przez inżynierię. Firma najbardziej prawdopodobna do bycia w pokoju, gdy transformacja agile jest nierozerwalnie związana z programem platform engineering, DevOps lub modernizacji chmurowej. Silny europejski autorytet marki. Mniej narracji senior-partnerskiej niż McKinsey czy Bain; większa głębia inżynierii dostarczania niż Deloitte czy KPMG.
Źródła: strony ADMnext, usług agile i Agile Innovation Center Capgemini.com · katalog Scaled Agile Global Transformation Partner · publikacje Capgemini Research Institute (CRI). Data snapshotu do przypięcia podczas researchu.
IBM Consulting
Nazwana oferta: IBM Garage Method (kanoniczna metodyka dostarczania agile-plus-inżynieria firmy), opakowana przez Enterprise Design Thinking na wejściu i koordynację zgodną z SAFe w skali. Dostarczana przez lokalizacje IBM Garage (studia fizyczne i wirtualne).
Warstwy metod: SAFe na poziomie programu — IBM jest SAFe Global Transformation Partner. Scrum na poziomie zespołu. Enterprise Design Thinking na wejściu do procesu. Garage Method integruje je w jeden cykl Discover-Envision-Develop-Reason-Operate-Culture.
Sygnaturowe IP: IBM Garage Method — dziedziczone IP, które najbardziej odróżnia IBM od Big Four. Enterprise Design Thinking (podejście IBM do ramowania problemów prowadzone przez design). Historyczny rodowód sięgający Rational Unified Process (RUP), oryginalnej ciężkiej metodyki iteracyjnej IBM przejętej wraz z Rational Software w 2003 roku. Sąsiedztwo: IBM Consulting Advantage i watsonx (z artykułu o AI) — zespoły dostarczania agile pracują na platformie Advantage i stosie modeli watsonx.
Nazwany flagowy case: American Airlines (transformacja prowadzona przez Garage, publicznie udokumentowana), USAA (zaangażowanie Garage w usługach finansowych), Travelport, liczne transformacje bankowe. Playbook Garage Method zawiera obszerny materiał case'owy.
Szkolenia/certyfikacja: IBM Skills Academy. Partner SAFe. Wewnętrzna ścieżka certyfikacji Garage Method dla konsultantów IBM. Certyfikacja Enterprise Design Thinking.
Vibe pozycjonowania: Zintegrowany design-thinking-do-inżynierii. Firma najbardziej prawdopodobna do bycia w pokoju, gdy zaangażowanie zaczyna się od ćwiczenia ramowania problemu prowadzonego przez design, a kończy dostarczaniem platform engineering. Mocna w assety (Garage Method, watsonx, Enterprise Design Thinking), nie w ceremonię. Najwyraźniejszy rodowód inżynieryjno-projektowy spośród wszystkich firm w tym porównaniu.
Źródła: strony produktowe IBM.com/garage · playbook IBM Garage Method (ibm.com/cloud/architecture lub kolejny URL) · strony Enterprise Design Thinking · publikacje agile i transformacyjne IBM Consulting. Data snapshotu do przypięcia podczas researchu.
Wielka tabela porównawcza
Tabela poniżej to asset referencyjny. Zestawia osiem frameworków na osiem wymiarów porównania, z firmami najaktywniej pakującymi każdy framework wskazanymi w skrajnie prawej kolumnie.
| Framework | Główny autor | Założenie skali | Stopień preskryptywności | Model governance | Głębia inżynierska | Ekosystem certyfikacji | Najaktywniej pakujące firmy |
|---|---|---|---|---|---|---|---|
| SAFe | Dean Leffingwell (Scaled Agile Inc.) | 50-125 na ART; portfolio > 1000 | Wysoki | Hierarchiczny (Portfolio → Team) | Nazwane DevOps + XP | SAFe SPC/SA/POPM/itd. (Scaled Agile Inc.) | Accenture · Deloitte · Capgemini · IBM · EY |
| LeSS | Craig Larman / Bas Vodde (LeSS Company) | 2-8 zespołów (LeSS); 8+ zespołów (LeSS Huge) | Niski-średni | Płaski (jeden PO) | Wysoka (doskonałość techniczna) | CLP, CLT (LeSS Company) | Mniejsi specjaliści; częściowe użycie u McKinsey, Bain |
| Scrum@Scale | Jeff Sutherland (Scrum Inc.) | Modularne; struktura SoS | Niski (modularny rdzeń) | Dwucyklowy (PO + SM) | Średnia (zależna od szkolenia) | SSM / SPS (Scrum Inc.) | BCG (wybiórczo); niezależni konsultanci |
| Spotify Model | Henrik Kniberg / Anders Ivarsson | Tribes / Squads (bez stałego rozmiaru) | Kulturowy, nie strukturalny | Macierzowy (Tribe × Chapter) | Domyślnie wysoka (inżynieria Spotify) | Brak oficjalnego | BCG (ING) · McKinsey · firmy natywnie cyfrowe |
| Disciplined Agile (DAD) | Scott Ambler / Mark Lines (PMI) | Toolkit; agnostyczny wobec cyklu życia | Napędzany wyborem (zorientowany na cele) | Pluralistyczny (agile/lean/plan-driven) | Szeroka (DevOps, bezpieczeństwo, architektura) | DAC, DASM, DAVSC (PMI) | Firmy dopasowane do PMI; dziedzictwo IBM |
| Nexus | Ken Schwaber (Scrum.org) | 3-9 zespołów Scrum, jeden produkt | Niski (rozszerzenie Scrum) | Skoncentrowany na zespole integracji | Średnia (dyscyplina integracji) | SPS, NXTC (Scrum.org) | Firmy dopasowane do Scrum.org; częściowo Accenture |
| Kanban Maturity Model (KMM) | David J. Anderson (Mauvius Group) | Od zespołu do enterprise, etapy dojrzałości 0-7 | Katalog praktyk | Oparty na flow, ewolucyjny | Agnostyczna | KMP, KCP (Kanban University) | Firmy mocno operacyjne; częściowo Capgemini |
| FAST | Ron Quartel | Plemię 30-150, dynamiczne zespoły | Radykalnie elastyczny | Spotkanie plemienia / marketplace | Wysoka (zakłada dojrzałą praktykę) | Brak mainstreamowego | Wyspecjalizowani coache; rzadko duże firmy |
Co jest naprawdę inne
- Tylko trzy frameworki publikują numerowaną metodykę, którą da się wdrożyć bez konsultanta. SAFe ma role, ceremonie, artefakty i Continuous Delivery Pipeline, które zespół transformacyjny może przeczytać i wykonać. LeSS ma opublikowane reguły wielozespołowego Scrum na jednym produkcie. Scrum@Scale ma SoS i dwa cykle koordynacji. Pozostałe pięć — Spotify, DAD, Nexus, KMM, FAST — to albo toolkity, migawki, albo minimalne rozszerzenia, które potrzebują albo doświadczonego praktyka, albo znaczącego istniejącego kontekstu, żeby wylądować. To nie jest ocena jakości: toolkity i migawki są czasem właściwą odpowiedzią. To jest ocena przejrzystości dla kupującego: tylko trzy z ośmiu frameworków zmniejszają zależność od konsultanta, którą framework miał zmniejszyć.
- Głębia inżynierii oprogramowania to najczystsza linia podziału w tym polu. LeSS i FAST zakładają dojrzałą praktykę inżynieryjną i nie wybaczają jej braku. SAFe i Nexus wprost nazywają praktyki inżynieryjne w swoich przewodnikach, ale liczą na to, że wprowadzi je implementer. Spotify, DAD, KMM i Scrum@Scale są w dużej mierze agnostyczne wobec praktyki inżynieryjnej. Kupujący, który uczciwie zna kulturę inżynieryjną swojej organizacji, może wprost przełożyć tę kolumnę na dopasowanie frameworka; kupujący, który jej nie zna, przyjmie framework, który boleśnie odsłoni tę lukę.
- Tylko dwa frameworki mają programy certyfikacji klasy dużych firm. SAFe (Scaled Agile Inc., dominujący, wiele certyfikacji dopasowanych do ról, duży ekosystem partnerski) i Disciplined Agile (własność PMI od 2019 roku, zintegrowany z certyfikatem PMP). Pozostałe sześć ma certyfikacje — LeSS Company, Scrum.org Nexus, Scrum Inc. Scrum@Scale, Kanban University KMP, społeczność fastagile.io — ale wolumen i penetracja wśród firm doradczych są o rząd wielkości niższe. To napędza efekt następczy, który kupujący rzadko widzą: rynek talentów nasycony SAFe oznacza, że ekspertyza SAFe jest naprawdę dostępna na zawołanie, w sposób nieprawdziwy dla LeSS czy FAST w skali enterprise.
- Spotify Model to najczęściej cytowany i najrzadziej wdrażany artefakt w tym polu. To nie jest framework. Oryginalny artykuł z 2012 roku opisywał, co Spotify robiło w tamtym czasie; późniejsze retrospektywy (Sundén 2017 i inni) jednoznacznie stwierdzają, że samo Spotify odeszło od tych diagramów w ciągu roku lub dwóch. A mimo to każda firma doradcza w tym porównaniu używa jakiejś wersji „tribes" i „squads" w swoich materiałach agile, a znaczna część publicznych transformacji agile cytuje Spotify jako model. Słownictwo się przenosi; kultura inżynieryjna, inwestycja w product management i infrastruktura platformowa, które sprawiały, że struktura Spotify działała — nie.
- FAST i Kanban Maturity Model to jedyne frameworki, które nie wymagają reorganizacji struktury zespołowej. Każdy inny framework na tej liście zakłada jakąś formę jawnej konfiguracji zespołu, czy to narzuconą (ARTy SAFe, zespoły feature'owe LeSS, zespoły Scrum Nexus), czy opisową (squady Spotify). KMM działa z istniejącą strukturą; FAST całkowicie rozpuszcza stabilną strukturę na rzecz płynnego codziennego formowania. Dla organizacji, gdzie reorganizacja jest politycznie lub praktycznie niemożliwa — konteksty poakwizycyjne, struktury regulowane, organizacje odbudowujące się po poprzedniej nieudanej transformacji — to najczystsza linia podziału w tym polu.
- Trzy firmy publikują merytoryczne IP metodyczne, które nie jest tylko przeklejeniem SAFe. Bain (książka Rigby'ego Doing Agile Right i seria artykułów HBR) ma opublikowaną metodykę z własną teorią o tym, gdzie agile mieści się w strategii korporacyjnej. McKinsey (Five Trademarks of Agile Organizations) ma diagnostykę na poziomie rady nadzorczej, która działa ponad każdym frameworkiem. IBM (Garage Method i Enterprise Design Thinking, z dziedzictwem Rational Unified Process) ma najdłużej działającą opublikowaną metodykę dostarczania w tym polu. Pozostałe siedem firm działa merytorycznie jako partnerzy SAFe z markowanymi opakowaniami, nawet tam, gdzie ich publiczne materiały odwołują się do innych metod.
Co jest głównie brandingiem
- Większość „ofert transformacji agile" Big Four to SAFe w opakowaniu markowanym przez firmę. Zdejmij markowaną diagnostykę, szablon PI Planning w barwach firmy i autorski model dojrzałości, a metoda bazowa pod spodem to SAFe w siedmiu z dziesięciu firm w tym tekście (wyjątkami są Bain, narracja McKinsey prowadzona przez diagnostykę i Garage Method IBM). To nie jest krytyka SAFe ani krytyka firm — SAFe zapracowało na swój udział w rynku — ale kupujący powinien wiedzieć, czy IP firmy to opakowanie, czy baza.
- „Tribes i squads" stało się słownictwem, nie metodą. Niemal każda firma w tym porównaniu używa języka wywodzącego się ze Spotify w swoich materiałach agile. Niemal żadna z nich nie dostarcza kultury inżynieryjnej, dyscypliny product management ani inwestycji w platformę wewnętrzną, które sprawiały, że struktura Spotify działała. Jeśli firma używa słownictwa Spotify, nie nazywając tego, co zrobi z praktykami inżynieryjnymi, wewnętrznymi platformami deweloperskimi i operating modelem product management, traktuj to słownictwo jako branding.
- Modele dojrzałości agile są w większości do siebie podobne. Cztery do pięciu poziomów. Ta sama garstka osi — zwykle jakaś kombinacja procesu, ludzi, technologii, kultury i wyników klienckich. Zestaw obok siebie modele dojrzałości agile dowolnych trzech firm, a podobieństwo strukturalne jest uderzające. Model dojrzałości służy konkretnemu celowi — czyni zaangażowanie czytelnym dla komitetu sterującego — ale rzadko jest faktycznym IP dostarczania firmy. IP tkwi w konsultantach, którzy przeprowadzają organizację przez te poziomy.
- Wolumen certyfikacji SAFe sygnalizuje mniej niż kiedyś. Strumień certyfikacji jest duży, pipeline masowego szkolenia jest dojrzały, a „świeżość" nowej certyfikacji nie jest tym, czym była dekadę temu. Liczba konsultantów certyfikowanych SAFe mówi ci, ilu ludzi firma przepuściła przez kurs, nie ilu dostarczyło transformację agile, która przetrwała weryfikację po pięciu latach. Pytaj o liczbę dostarczonych zaangażowań, nie o liczbę certyfikatów.
- Większość „flagowych case'ów" nie przetrwa uczciwej weryfikacji po pięciu latach. Najczęściej cytowana transformacja współczesnej ery — restrukturyzacja ING Bank inspirowana Spotify z lat 2015-2018, opowiadana przez BCG i McKinsey — istotnie wyewoluowała w kolejnych latach, a obecna organizacja ING wygląda znacząco inaczej niż diagram z 2017 roku. Ten wzorzec nie jest unikalny dla ING; to reguła, nie wyjątek. Opublikowany flagowy case firmy to migawka jednego momentu w długim programie. Pytaj, jak case wygląda dzisiaj, nie jak wyglądał w decku.
Rzeczywistość 2026: AI, mniejsze zespoły, platform engineering
Każdy framework w tym porównaniu został zaprojektowany, zanim AI generatywne zmieniło rozmiar zespołu dostarczającego dane zadanie. Implikacje jeszcze nie pojawiają się w przewodnikach po frameworkach — SAFe 6.0 robi tylko skromne gesty w stronę AI, przewodnik LeSS milczy, retrospektywy modelu Spotify poprzedzają obecny moment AI — ale są widoczne w transformacjach 2026 roku.
AI generatywne kompresuje rozmiar zespołu. Zadanie produktowe, które w 2018 roku wymagało plemienia osiemdziesięciu inżynierów, projektantów i product managerów, w wielu przypadkach da się dostarczyć w 2026 roku ośmioma do piętnastoma osobami, korzystając z rozwoju wspomaganego AI, pokrycia testami generowanego przez AI i designu wspomaganego AI. Frameworki zbudowane dla programów o dużym headcouncie — SAFe na poziomie ART w szczególności, z jego założeniem 50-125 osób i logistyką PI Planning — są pod presją strukturalną. Frameworki, które skalują się w dół bez strat (FAST, KMM, Nexus i LeSS na dolnym końcu swojego zakresu), cicho zdobywają grunt.
Platform engineering zastępuje część ceremonii koordynacyjnych. Wewnętrzne platformy deweloperskie wykonują dziś pracę międzyzespołową, która wcześniej siedziała w spotkaniach Scrum-of-Scrums, salach PI Planning i rytuałach zespołu integracyjnego. Gdy platforma wchłania koordynację, framework potrzebuje jej mniej. Frameworki agile najbardziej pod presją to te, których propozycja wartości opierała się głównie na „ceremoniach koordynacyjnych i wspólnej kadencji". Frameworki najbardziej wzmocnione to te, których propozycja wartości opierała się głównie na „praktyce inżynieryjnej i flow".
Remote-first zmienia ekonomikę ceremonii kolokowanych. PI Planning przez Zoom nie jest tym, czym PI Planning było w centrum konferencyjnym z osiemdziesięcioma osobami na karteczkach. Frameworki zależne od konkretnej jakości rytuału kolokowanego są słabsze niż były; frameworki, które działały przez dowolne medium komunikacji (tablice flow KMM, dyscyplina integracji Nexus), utrzymały się lepiej. To nie jest wyrok na pracę zdalną; to obserwacja, które frameworki wliczyły swoje ceremonie w propozycję wartości.
Reguła decyzyjna się przesunęła. Pytanie o wybór frameworka w 2018 roku brzmiało „który framework się skaluje?". W 2026 roku bliżej mu do „który framework przetrwa pięćdziesięcioprocentowe cięcie headcountu bez utraty tożsamości?". SAFe-at-Portfolio przetrwa cięcie, zmniejszając liczbę ARTów, ale sam ART SAFe jest niezręczny przy mniej niż pięćdziesięciu osobach. LeSS skaluje się w dół do dwóch zespołów bez strat. KMM w ogóle nie wymaga struktury zdefiniowanej headcountem. Plemiona w stylu Spotify tracą tożsamość, gdy plemię zapada się do jednego squada.
To przesunięcie łączy się bezpośrednio z pytaniem kupującego, które badaliśmy w towarzyszącym tekście, The Big Consulting AI Frameworks, Compared. AI to nie tylko technologia do wdrożenia; to zmiana w ekonomice jednostkowej dostarczania oprogramowania. Framework agile pasujący do organizacji nasyconej AI w 2026 roku rzadko jest tym samym frameworkiem agile, który pasował do tej samej organizacji w 2018 roku, nawet gdy nic innego w tej pracy się nie zmieniło. Frameworki, które w tym środowisku wyglądają najsilniej, to te zbudowane wokół flow i praktyki inżynieryjnej; frameworki, które wyglądają najsłabiej, to te zbudowane wokół koordynacji ciężkiej headcountem.
Jak to czytać, jeśli jesteś kupującym
Jeśli jesteś CEO, członkiem rady nadzorczej, transformation officerem albo inwestorem PE, debata o frameworku niemal nigdy nie jest najbardziej użytecznym miejscem, żeby wydać energię decyzyjną. Pięć scenariuszy poniżej pokrywa większość tego, co faktycznie pojawia się w propozycjach transformacji agile; wybierz pasujący scenariusz, zobacz, co mówi ci dopasowanie frameworka, i użyj trzech pytań na końcu, żeby przeczytać ofertę dowolnej firmy w pięć minut.
Scenariusz 1 — skalowanie mid-marketu (300-2000 pracowników, szybki wzrost). Właściwą odpowiedzią rzadko jest SAFe; jest za ciężki na ten rozmiar, a ekosystem certyfikacji jest skalibrowany pod większe przedsiębiorstwa. Spójrz na Scrum@Scale albo LeSS na dolnym końcu jego zakresu. Wybór firmy to zwykle wyspecjalizowana firma doradcza agile albo starszy niezależny praktyk; Big Four są skalibrowane pod większe zaangażowania, a koszt dostępu jest wysoki względem wartości, jaką wyciągniesz przy tym rozmiarze.
Scenariusz 2 — branża regulowana (bankowość, farmacja, regulowane usługi użyteczności publicznej, obronność). SAFe wygrywa pod względem przyjazności audytowej z dużą przewagą — nazwane role, możliwe do prześledzenia artefakty, certyfikowani konsultanci przechodzący filtry zamówień publicznych. Wybór firmy to Deloitte, Accenture, Capgemini, KPMG albo EY, w zależności od obecności regionalnej i istniejącej relacji. Kompromis, który zawierasz, to głębia praktyki inżynieryjnej w zamian za czytelność governance; zabudżetuj osobno wypełnienie luki inżynieryjnej.
Scenariusz 3 — integracja poakwizycyjna. Dwie kultury dostarczania, często dwa łańcuchy narzędziowe, często dwa istniejące warianty agile, które się nie zgadzają. Pluralistyczny model cyklu życia DAD pasuje do tego wzorca lepiej niż jakikolwiek framework jednofilozoficzny; KMM działa dobrze, gdy reorganizacja jest politycznie wykluczona. Firmy dopasowane do PMI albo wyspecjalizowane firmy doradcze od integracji poakwizycyjnych. Unikaj wymuszania jednej strony na frameworku drugiej jako ruchu integracyjnego — koszt polityczny rzadko usprawiedliwia metodologiczną czystość.
Scenariusz 4 — program mocno oparty na AI. Mniejsze zespoły, szybsze cykle, zależność od platform engineering. FAST albo LeSS na dolnym końcu pasują lepiej niż SAFe; KMM sprawdza się dla strony operacyjnej tego samego programu. Wybór firmy w dużej mierze pokrywa się z decyzją dotyczącą doradztwa AI — zobacz towarzyszący tekst o AI dla tego wyboru. Framework agile jest warstwą dostarczania dla pracy AI; wybierz go pod dopasowanie praktyki inżynieryjnej, nie pod gęstość ceremonii.
Scenariusz 5 — klasyczne przejście z IT do produktu. Tradycyjna organizacja dostarczania IT przechodząca do zespołów prowadzonych przez produkt, zorientowanych na wyniki. Struktury inspirowane Spotify z głęboką inwestycją w kulturę inżynieryjną to podręcznikowa odpowiedź; podręcznik jest często źle odczytywany. BCG albo McKinsey dostarczają nakładkę projektowania organizacyjnego i narrację na poziomie rady nadzorczej; praca inżynieryjna jest trudną częścią i rzadko tą częścią, do dostarczenia której firma strategiczna jest najlepiej pozycjonowana. Zaplanuj drugie zaangażowanie prowadzone przez inżynierię — Capgemini albo wyspecjalizowaną firmę platform engineering — obok pracy strategicznej.
Trzy pytania tną ofertę firmy szybciej niż jakakolwiek macierz punktacji:
- „Pokaż mi praktykę inżynieryjną, którą twój zespół dostarczy, szczegółowo, w poniedziałek." Jeśli firma nie potrafi szczegółowo opisać praktyki inżynieryjnej swojego zespołu — trunk-based development, konfiguracji CI, podejścia do pokrycia testami, dyscypliny code review, narzędzi platformowych — kupujesz ceremonię, nie dostarczanie. To czasem właściwy wybór. Wiedz, że właśnie go dokonujesz.
- „Pokaż mi, jak wygląda dzisiaj struktura twojego ostatniego zaangażowania." Frameworki ewoluują, a uczciwa odpowiedź ujawnia, co przetrwało zderzenie z organizacją. Firmy, które nie potrafią powiedzieć, jak wygląda ich ostatnie zaangażowanie w 2026 roku, albo nie są zaangażowane w rzeczywistość po zakończeniu współpracy, albo nie chcą się nią dzielić. Oba to użyteczne sygnały.
- „Kto jest właścicielem pracy integracyjnej między zespołami i jak jest obsadzona?" Koordynacja to prawdziwy koszt scaled agile. Najczęstszy wzorzec porażki to framework, który nazywa rolę integracji na slajdzie i zostawia ją nieobsadzoną w zaangażowaniu. Pytaj kto, pytaj o CV, pytaj o linię raportowania. Jeśli odpowiedzi są niejasne, integracja zostanie opłacona opóźnieniami w dostarczaniu.
Gdzie pasuje Consulting Huber
Consulting Huber jest firmą praktyków, nie rywalem Big Four czy MBB. Nie konkurujemy na rozmiarze ławki certyfikowanej SAFe, globalnym śladzie dostarczania ani wolumenie nazwanych flagowych case'ów. Konkurujemy na odwrotnym problemie: transformation officerowie, CEO, rady nadzorcze i inwestorzy PE, którzy chcą metodyki i dyscypliny inżynieryjnej dużej firmy, dostarczonej bezpośrednio przez starszych praktyków, z przekazaniem zdolności zespołowi klienta na koniec zaangażowania.
To znaczy, że powiemy ci, który framework naprawdę pasuje do kultury inżynieryjnej twojej organizacji, a nie który framework faworyzuje nasz stos certyfikacji. To znaczy, że będziemy z tobą pracować, żeby właściwie obsadzić rolę integracji, zamiast tylko nazwać ją na slajdzie. To znaczy, że pozwolimy ci zachować prawo do zwolnienia nas na koniec każdego cyklu, bo model to transfer zdolności, nie platform lock-in.
Towarzyszący tekst po stronie AI — jak tych samych dziesięć firm ramuje transformację AI i GenAI, z tą samą perspektywą kupującego — znajduje się pod The Big Consulting AI Frameworks, Compared (2026). Nasza strona usługowa o pracy agile end-to-end jest pod Business agility. Jeśli chcesz spojrzenia łączącego AI i agile, pokazującego, jak te dwa teksty łączą się w realnym programie, AI value creation playbook jest trzecim rogiem trójkąta.
Konsultowane źródła
Źródła pierwotne — teksty kanoniczne frameworków
Leffingwell, D., SAFe Reference Guide (Scaled Agile Inc., aktualna edycja dla 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
Źródła pierwotne — strony produktowe firm (data snapshotu 2026-05-14)
BCG
Strony produktowe Agile at Scale BCG.com · publikacje BCG „Agile Performance Management" · strony produktowe BCG X — jednostki tech build — relacje BCG o case study transformacji ING Bank. Konkretne URL-e do przypięcia podczas snapshotu.
McKinsey & Company
Bazigos, M., De Smet, A., and Gagnon, C., “The five trademarks of agile organizations” (McKinsey & Company, 2018) · artykuły agile McKinsey Quarterly (Aghina, De Smet i in., wiele lat) · case studies ING Bank McKinsey · publikacje McKinsey Organizational Health Index. Konkretne URL-e do przypięcia podczas snapshotu.
Deloitte
Strony produktowe Agile@Scale Deloitte.com · wpis w katalogu Scaled Agile Inc. Global Transformation Partner · publikacje agile i transformacyjne Deloitte Insights · regionalne artykuły Deloitte Agile Maturity Model. Konkretne URL-e do przypięcia podczas snapshotu.
EY (i EY-Parthenon)
Strony produktowe Business Agility EY.com · strony frameworka EY Transformation Realized · publikacje EY Wavespace · insighty strategiczno-transformacyjne EY-Parthenon. Konkretne URL-e do przypięcia podczas snapshotu.
PwC
Strony produktowe Business Transformation i Digital Transformation PwC.com · publikacje metodyki PwC BXT (Business-Experience-Technology) · PwC Global CEO Survey (wnioski dotyczące agile i transformacji). Konkretne URL-e do przypięcia podczas snapshotu.
KPMG
Strony produktowe agile-transformation i Connected Enterprise KPMG.com · publikacje KPMG Powered Enterprise · przegląd programu KPMG Lakehouse · globalne insighty transformacyjne KPMG advisory. Konkretne URL-e do przypięcia podczas snapshotu.
Accenture
Strony produktowe Business Agility i Agile Engineering Studios Accenture.com · strony rozwiązań branżowych Accenture myConcerto · publikacje Accenture ADM i ADMnext · wpis w katalogu Scaled Agile Inc. Global Transformation Partner · komunikaty Accenture-NVIDIA Business Group. Konkretne URL-e do przypięcia podczas snapshotu.
Bain & Company
Strony produktowe Agile Innovation Bain.com · 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 (coroczny). Konkretne URL-e do przypięcia podczas snapshotu.
Capgemini
Strony produktowe ADMnext Capgemini.com · strony usług agile i DevOps Capgemini · strony Capgemini Agile Innovation Center · wpis w katalogu Scaled Agile Inc. Global Transformation Partner · publikacje Capgemini Research Institute (CRI). Konkretne URL-e do przypięcia podczas snapshotu.
IBM Consulting
Strony produktowe ibm.com/garage · playbook IBM Garage Method · strony IBM Enterprise Design Thinking · publikacje IBM Consulting Advantage · materiały case study IBM American Airlines, USAA i innych zaangażowań Garage. Konkretne URL-e do przypięcia podczas snapshotu.
Benchmarki zewnętrzne i społeczność
Katalog partnerów Scaled Agile Inc. i dane o adopcji enterprise · State of Agile Report (digital.ai, coroczne edycje) · statystyki społeczności i dane o adopcji Scrum.org · biblioteka case studies LeSS Company · materiały społeczności Kanban University. Konkretne URL-e do przypięcia podczas snapshotu.
Wywiady z praktykami przeprowadzone na potrzeby tej edycji
Do uzupełnienia podczas researchu: nazwane rozmowy z autorami frameworków i starszymi praktykami firm, tam gdzie wyrażają zgodę na przypisanie. Teksty referencyjne zyskują istotnie na jednym lub dwóch cytatach on-the-record; outreach jest w toku na datę snapshotu.
Jak cytować ten artykuł
Styl APA:
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/pl/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/pl/agile-consulting-frameworks-compared.html}
}
Data snapshotu: 14.05.2026. Planowana coroczna aktualizacja; kolejne edycje zachowają poprzednią pod datowanym URL-em.
Zobacz też: Business agility service · Porównanie frameworków AI (tekst towarzyszący) · AI value creation playbook · Case studies · Wszystkie usługi