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)
A practitioner reference: what the eight scaled-agile frameworks actually prescribe, what the ten major consulting firms add on top, and how a buyer should read the difference — with primary sources and named flagship cases throughout.
Why compare at all?
“SAFe versus LeSS” gets Googled a million times. “Spotify model alternatives” gets Googled another half million. Behind those queries is almost never a transformation officer doing comparative literature. It is a CEO, a CIO, or a board member trying to work out, before next week's meeting, what their consulting partner is actually going to do on Monday morning — and whether the agile flavor on the proposal is real method, real engineering, or a relabeling of the same Spotify-tribe slide that won the last three pitches.
The honest answer is harder to find than it should be. Most public framework comparisons are written by the method vendors themselves — Scaled Agile Inc. on SAFe, the LeSS Company on LeSS, Scrum Inc. on Scrum@Scale — and they all win the argument they wrote. The consulting firms publish thought leadership about their own offerings without admitting which base method they layered, which they quietly avoid, or which produced an engagement that has since been rolled back. The buyer is left to triangulate, usually under time pressure, between a method site that wants certification revenue and a firm site that wants a contract.
This piece is a buyer's-seat practitioner reference. The framing is this: there are eight scaled-agile frameworks worth knowing in 2026, and ten consulting firms that sell agile transformations in volume. Each framework is a real product with a real author, a real theory of scale, and a real opinion about engineering practice. Each firm wraps one or more of those frameworks with branded IP, a certification stack, and a flagship case. The interesting questions are the ones the firms and method vendors are least likely to answer themselves: where the wrapper adds genuine method, where it adds only brand, where the named flagship case looks the same five years on, and where the framework's engineering assumptions still hold once you account for AI-era team sizes.
We have a preference, and we will say it up front to keep the rest of the piece honest. Agile is not the product. Agile is the delivery layer underneath every AI, digital, and operational programme that needs to keep shipping after the launch ceremony. The framework that does this best for any given organisation is rarely the one with the largest certification ecosystem or the loudest brand. It is usually the one whose engineering assumptions, governance shape, and team-size sweet spot fit the work in front of the buyer this quarter. Picking it wrongly is the most expensive mistake in transformation budgets, and the one that gets attributed to “culture” in the post-mortem.
What follows is structured so a CEO can read it in fifteen minutes and a transformation officer can use it as a working reference. Section 3 places the eight frameworks in the timeline that produced them, because none of this work makes sense without the history. Sections 4 and 5 compare the frameworks and the firms side by side. Section 6 is the table you can screenshot. Sections 7 and 8 say what is different and what is dressing. Section 10 gives you the buyer's-seat decision tree. Section 11 says where we fit.
A note on method
The snapshot date for this comparison is 14 May 2026. Framework guides, firm capability pages and case-study libraries change; everything below reflects the public state on that date. Subsequent editions will preserve the previous edition at a dated URL so anyone citing this piece can pin the version they referenced.
Primary sources for the eight frameworks. Where a framework has a canonical book, the book is the primary source. SAFe: Dean Leffingwell, SAFe Reference Guide (Scaled Agile Inc., current edition for SAFe 6.0). LeSS: Craig Larman and Bas Vodde, Large-Scale Scrum: More with LeSS (Addison-Wesley, 2017), plus their earlier 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 and Sutherland, 2014). Spotify Model: Henrik Kniberg and Anders Ivarsson, “Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds” (2012), plus the Spotify Engineering Culture videos (Kniberg, 2014) and the subsequent retrospectives from Joakim Sundén and Marcin Floryan. Disciplined Agile: Scott Ambler and Mark Lines, Choose Your WoW! (PMI, current edition). Nexus: Ken Schwaber and Scrum.org, The Nexus Guide. Kanban Maturity Model: David J. Anderson and Teodora Bozheva, Kanban Maturity Model (Lean Kanban Inc., 2018). FAST: Ron Quartel, The FAST Guide, plus community talks.
Primary sources for the ten firms. Each firm is sourced from its own published capability pages, white papers and press releases at the snapshot date, plus — where they exist — publicly named flagship case studies. Where a firm is a SAFe Global Transformation Partner, the public partner directory is treated as an independent corroborating source. Industry-wide adoption data is drawn from the State of Agile annual report (digital.ai) and Scrum.org community statistics. We avoid citing internal firm interviews; everything below has a public source.
What's in scope, and what isn't. In: frameworks with a named author, a published methodology and an active practitioner community at the team-of-teams level or higher. In: firms that publish a branded agile-transformation offering and have a meaningful certified or specialist consultant bench. Out: pure team-level frameworks (Scrum, Extreme Programming, single-team Kanban — these are inputs to the scaled frameworks, not competitors of them). Out: agile coaching certifications without a delivery methodology underneath. Out: boutique consultancies under fifty consultants — the buyer's question this piece serves is about firms that can mobilise an enterprise programme.
Why eight frameworks, not six or twelve. Six understates the field: omitting Kanban Maturity Model and FAST would erase the two frameworks that explicitly do not require a team-structure reorganisation, which is exactly the situation many post-merger or politically constrained organisations face. Twelve overstates it: most of the additional frameworks (Nexus+, Disciplined Agile Enterprise, individual firm wrappers) are extensions or rebrands of the eight here. The eight in this piece have either a named author with a published method and an active community, or are the only branded asset a major firm publishes under their own name.
A brief history of scaled agile (2001-2026)
None of the frameworks in this comparison make sense without the history. Scaled agile is a twenty-five-year argument about how to ship software at a size and pace the original Agile Manifesto authors never tried to handle, and almost every disagreement in the current literature can be traced back to which year, which problem and which engineering culture produced the framework that argues it.
2001 — Agile Manifesto. Seventeen practitioners meet at Snowbird, Utah and publish four values and twelve principles. Every framework in this piece is, in some form, a descendant. Critically, the Manifesto is silent on coordination across more than one team. That silence is the gap the rest of this history fills.
1994-1999 — the pre-history. DSDM (Dynamic Systems Development Method) is published in 1994 in the UK, with an explicit scaling story for fixed-budget delivery. FDD (Feature-Driven Development) appears in 1997 from Jeff De Luca's work in Singapore. RUP (Rational Unified Process) is finalised at Rational Software in 1998 and acquired by IBM in 2003, giving large enterprises a heavyweight iterative process they could buy. None of these are "agile" by the 2001 definition, but they prove the same problem — multi-team, multi-phase coordinated delivery — was already being solved before the Manifesto named the value system.
2007-2010 — Scrum scales by accident. Scrum (Schwaber and Sutherland, formalised in the 1990s, popularised after the Manifesto) becomes the dominant team-level method. Larger organisations adopt it, hit the limit of a single Scrum team and start inventing local solutions. The "Scrum of Scrums" pattern is documented but ungoverned. The first published attempts at deliberate scaling appear in this period — Craig Larman and Bas Vodde's Practices for Scaling Lean & Agile Development (2008) is the earliest serious treatment in book form.
2011 — SAFe 1.0. Dean Leffingwell publishes the first Scaled Agile Framework. It is the first scaled-agile framework that looks like a buyable product: numbered roles, named ceremonies (most famously PI Planning), a portfolio layer above the program layer, and a certification stack. Enterprise transformation officers, who had been struggling to map team-level Scrum onto programme-level governance, finally have something they can put on a slide. Scaled Agile Inc. is founded the same year. From this point onwards, every other framework in the field defines itself in part by where it agrees with or rejects SAFe.
2012-2014 — Spotify and LeSS. Henrik Kniberg and Anders Ivarsson publish “Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds” in 2012. It is a whitepaper, not a framework. The vocabulary — tribes, squads, chapters, guilds — spreads faster than any framework before or since. In 2014, Kniberg releases the Spotify Engineering Culture videos. The same year, Larman and Vodde launch the LeSS framework publicly on less.works, positioning it explicitly as “Scrum with the rules you need to scale it” — a deliberate counter-position to SAFe's role and ceremony density.
2014-2015 — Scrum@Scale and Disciplined Agile. Jeff Sutherland publishes Scrum@Scale, keeping the original Scrum minimalism at the core and adding two coordination cycles (Scrum Master cycle and Product Owner cycle). Scott Ambler and Mark Lines, originally at IBM, publish Disciplined Agile Delivery as a toolkit-style alternative that supports plan-driven, agile and lean lifecycles in the same programme — a deliberate accommodation of enterprises that cannot adopt a single delivery philosophy.
2015-2016 — Nexus. Ken Schwaber and Scrum.org launch Nexus as the “Scrum, just a bit bigger” option: an exoskeleton for three to nine Scrum teams sharing a product, with a Nexus Integration Team owning cross-team integration. Lower brand surface than SAFe or LeSS, but cleaner for teams already committed to the Scrum.org ecosystem.
2018 — Kanban Maturity Model and the Five Trademarks. David J. Anderson and Teodora Bozheva publish the Kanban Maturity Model, formalising a maturity-staged practice catalogue that does not require team-structure changes — the first framework explicitly designed for organisations that cannot or will not reorganise. The same year, McKinsey publishes “The five trademarks of agile organizations” (Bazigos, De Smet, Gagnon), giving consulting firms a non-framework diagnostic they can sell into board rooms.
2017-2019 — FAST and PMI's DAD acquisition. Ron Quartel publishes the FAST framework in 2017 — the most radically flexible of the set, with dynamic team formation and no Scrum Masters. In 2019 PMI acquires Disciplined Agile, giving the framework enterprise credibility and slowing its open-community velocity in roughly equal measure.
2019-2022 — SAFe consolidation, Spotify retrospectives. SAFe wins the regulated-industries argument by default: it is the only framework with audit-friendly named roles, certification, and a Scaled Agile Inc. partner ecosystem that lets a buyer get specialist consultants on call. In parallel, Joakim Sundén and others from the original Spotify period publish retrospectives clarifying that the “Spotify Model” was always a snapshot, never a model — and that Spotify itself has long since evolved past those diagrams.
2023-2026 — AI-era pressure. Generative AI compresses team size. Workloads that needed a tribe of eighty in 2018 can be delivered by eight to fifteen people with platform-engineering and AI-assisted development. Platform engineering replaces some coordination ceremonies with internal developer platforms. The frameworks under structural pressure are the ones built for headcount-heavy programmes; the frameworks gaining quiet ground are the ones that scale down cleanly (FAST, KMM, LeSS) or that survive a headcount cut without losing identity.
That is the canon. The eight frameworks compared in the next section are the eight that survived this twenty-five-year argument with a published method, a named author, and an active community in 2026. Everything else is either a team-level method (out of scope), a vendor wrapper of one of these eight (Section 5), or an idea that did not survive contact with enterprise budgets.
Eight frameworks, eight framings
Each method is its own product, with its own author, its own assumptions about scale, and its own theory about where software-engineering practice fits. The order below is roughly by adoption weight in enterprise consulting engagements, not by quality.
1. SAFe — Scaled Agile Framework
Author / origin: Dean Leffingwell, first public release 2011, SAFe 6.0 current as of 2023. Owned and trademarked by Scaled Agile Inc.
Scale assumption: Built around the Agile Release Train (ART) of 50-125 people. The Large Solution and Portfolio configurations extend coordination to multi-ART programmes of several thousand. Designed top-down to fit enterprises, not bottom-up from team-level Scrum.
Prescriptive vs flexible: The most prescriptive framework in this comparison. Named roles (RTE, Product Manager, Solution Train Engineer, System Architect, Business Owner, Release Train Engineer, plus team-level Scrum Master and Product Owner). Named cadences (the PI — Program Increment — usually 8-12 weeks). Named ceremonies (PI Planning, System Demo, Inspect & Adapt). Named artifacts (Programme Backlog, Solution Backlog, Portfolio Kanban).
Governance shape: Hierarchical — Portfolio → Large Solution → Essential (ART) → Team. Portfolio Lean Budgeting layer with Strategic Themes and Value Streams. Audit-friendly: every role, ceremony and decision can be traced.
Software-engineering depth: DevOps and the Continuous Delivery Pipeline are named, top-level pillars. Built-In Quality, Test-First and the underlying XP practices are explicitly referenced. In practice the engineering depth depends almost entirely on the SPC (SAFe Programme Consultant) running the implementation; ceremony adoption typically outpaces engineering adoption.
Where it shines: Regulated industries (banks, pharma, defence) that need audit-traceable governance. Large enterprises with mature programme management offices that already think in roles and ceremonies. Multi-vendor delivery contexts where shared cadence and named coordination roles reduce integration risk.
Where it gets misapplied: Small organisations that adopt the full framework because the certification path made it visible. PI Planning theatre — the two-day ceremony adopted as ritual without the underlying engineering practice that makes the next twelve weeks deliverable. Portfolio Kanban as a budget-justification artefact rather than a flow tool. Any deployment where the SPC has never written production code.
Vibe assessment: The framework that scaled because it survived enterprise scrutiny. Loved by transformation officers because every conversation they need to have with a board has a named SAFe artefact behind it. Suspected by senior engineers because the same conversation rarely connects to a CI pipeline. The most common gap between the SAFe diagram on the wall and the engineering practice in the IDE.
Sources: Leffingwell, SAFe Reference Guide (Scaled Agile Inc.) · scaledagileframework.com · Scaled Agile Inc. partner directory · State of Agile Report (digital.ai, annual)
2. LeSS — Large-Scale Scrum
Author / origin: Craig Larman and Bas Vodde, evolved from their work at Nokia Siemens Networks in the mid-2000s. First book Practices for Scaling Lean & Agile Development (2008); the LeSS framework formalised on less.works in 2014; Large-Scale Scrum: More with LeSS (2017) is the canonical text.
Scale assumption: One product, one Product Owner, one Product Backlog. LeSS proper covers 2-8 teams. LeSS Huge covers 8+ teams, organised into Requirement Areas each with an Area Product Owner. The single-product assumption is the framework's central commitment and its hardest constraint to meet.
Prescriptive vs flexible: Minimalist by design. The slogan is “Scrum applied to many teams working together on one product”, with only the additional rules needed to make that work — not a parallel programme layer. Fewer named roles, fewer named events, no portfolio overlay.
Governance shape: Deliberately flat. One Product Owner across all teams (or one Area PO per Requirement Area in LeSS Huge). No separate programme layer. No Release Train Engineer equivalent. Cross-team coordination happens through Multi-Team PBR, Overall Retrospective and component-mentor / travelling-engineer patterns, not through a hierarchical role.
Software-engineering depth: Among the highest of the eight. Continuous Integration is non-negotiable. The framework explicitly demands technical excellence: refactoring, simple design, test-driven development and shared code ownership are treated as preconditions, not aspirations. Larman and Vodde have written extensively on the engineering practices LeSS assumes.
Where it shines: Single-product organisations with engineering cultures already inclined to flatten hierarchy. Software product companies, platform teams inside larger enterprises, organisations willing to dismantle component-team and functional silos in favour of feature teams.
Where it gets misapplied: Multi-product portfolios that try to force the single-PO assumption. Regulated industries where audit expects named compliance roles that LeSS does not provide. Organisations that adopt the structure but skip the engineering preconditions — LeSS without continuous integration is just Scrum with extra retros.
Vibe assessment: The framework engineers respect. The framework transformation officers find hardest to sell to a board because it offers fewer brand-recognisable artefacts than SAFe. The one that gives the best results in the hands of a strong technical leadership team, and the worst results when imposed on an organisation that has not yet earned the engineering discipline it presumes.
Sources: Larman and Vodde, Large-Scale Scrum: More with LeSS (Addison-Wesley, 2017) · less.works · LeSS Company certification (CLP, CLT) · Larman and Vodde, Practices for Scaling Lean & Agile Development (2008)
3. Scrum@Scale
Author / origin: Jeff Sutherland (co-creator of Scrum with Ken Schwaber), founder of Scrum Inc. Published in 2014, current Scrum@Scale Guide version 3.0 (2022). Built on top of the underlying Scrum Guide that Sutherland and Schwaber co-author.
Scale assumption: Modular and recursive. Five teams form a Scrum of Scrums (SoS); five SoS form a Scrum of Scrums of Scrums; and so on. No hard team-count limit. The Executive MetaScrum sits at the top as the strategic priority-setting forum. The framework is built to scale by repeating the same pattern at higher levels, rather than introducing new layers with new roles at each level.
Prescriptive vs flexible: Minimal core, modular accretion. The only required roles are the standard Scrum roles (Scrum Master, Product Owner, Developer). All additional components — the SoS, the SoSoS, the Executive Action Team, the Executive MetaScrum — are added only as the organisation requires them. Closer to a meta-framework than to a single prescribed implementation.
Governance shape: Two parallel cycles. The Scrum Master cycle handles “how” — impediment removal, continuous improvement, cross-team coordination. The Product Owner cycle handles “what” — backlog prioritisation, strategic vision, customer feedback. Each cycle has its own meeting cadence and accountability owner.
Software-engineering depth: Light explicit guidance in the framework itself. Sutherland's books and Scrum Inc. training carry strong engineering-practice content but the framework guide does not mandate specific practices. In practice this means engineering depth depends on the Scrum Inc.-certified trainer or consultant running the implementation.
Where it shines: Organisations that already run Scrum effectively at the team level and need coordination at the multi-team level without inheriting a SAFe-grade overlay. Mid-market technology companies. Engineering-led organisations that want their existing Scrum culture preserved through the scale-up.
Where it gets misapplied: Organisations that mistake minimalism for ambiguity and abandon the framework before the modular components settle in. Transformation programmes that expect prescription and find Scrum@Scale's optionality unsettling. Implementations that adopt the SoS pattern without the corresponding Product Owner cycle, producing coordination overhead without strategic alignment.
Vibe assessment: Sutherland's name carries enormous weight. The framework has a smaller open community than SAFe or LeSS but a high concentration of Scrum Inc.-trained consultants in the field. The framework most often cited when an organisation says “we want to scale our team-level Scrum without rebranding it”. Less brand surface than SAFe; cleaner conceptual structure than LeSS Huge.
Sources: scrumatscale.com · The Scrum@Scale Guide v3.0 (Scrum Inc., 2022) · Sutherland and Sutherland, Scrum: The Art of Doing Twice the Work in Half the Time (Random House, 2014) · Scrum Inc. certification (SSM, SPS)
4. Spotify Model
Author / origin: Henrik Kniberg and Anders Ivarsson, “Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds” (2012). Followed by Kniberg's Spotify Engineering Culture videos (Part 1 and Part 2, 2014). Never published as an official framework by Spotify; the original papers describe what Spotify was doing at the time, with explicit warnings that the model would continue to evolve. Subsequent retrospectives (Joakim Sundén 2017, Marcin Floryan and others) have repeatedly made the point that Spotify itself moved past the diagrams within a year or two.
Scale assumption: Squads of typically 6-12 people, cross-functional, autonomous. Tribes group related squads, capped (at Spotify) at around 100 people to preserve a sense of belonging. Chapters cross-cut tribes by discipline (engineering, design, data). Guilds are voluntary interest groups that span the whole organisation.
Prescriptive vs flexible: Culturally prescriptive, structurally suggestive. The cultural prescriptions — autonomy with alignment, trust over control, “loosely coupled, tightly aligned” — are concrete and demanding. The structural elements (tribes, squads, chapters, guilds) are descriptive of what Spotify did, not mandated as a framework anyone else should adopt verbatim.
Governance shape: Matrix. Tribes own product outcomes and roadmaps. Chapters own discipline standards and people management for their members. Guilds own cross-cutting topics by interest. Critically, the Spotify governance assumed a strong product-management function and a strong engineering platform — neither named explicitly in the diagrams, both essential in practice.
Software-engineering depth: Implied, not specified. The model assumes a strong engineering culture: trunk-based development, continuous deployment, internal platforms, and a high bar for autonomy without architectural drift. Adopters who copy the org chart without the engineering platform get coordination chaos, not autonomy.
Where it shines: Technology-native, product-led organisations with significant existing investment in platform engineering and developer experience. Organisations that have already earned the engineering autonomy the model assumes. Often, the most useful application of the Spotify Model is as a vocabulary for organisations that already function this way and need names for what they do.
Where it gets misapplied: The dominant failure mode. Organisations copy the org chart — tribes, squads, chapters — without the engineering culture, the product-management function, or the platform investment that made the structure work. They get the diagram and not the outcomes. Spotify's own retrospectives are explicit: the model was a snapshot, the snapshot is dated, and treating it as a target architecture is a mistake.
Vibe assessment: The most influential, least implementable artefact in the field. The framework people quote when they mean “we want to be more like Spotify” — which almost always means they have read the diagram but not the engineering posts. Useful as a vocabulary, dangerous as a template. The cleanest sign that an organisation has read past the diagram: they refer to the post-2017 retrospectives, not just the 2012 paper.
Sources: Kniberg and 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 and others, subsequent Spotify retrospectives
5. Disciplined Agile (DA / DAD)
Author / origin: Scott Ambler and Mark Lines, originally developed at IBM Rational from around 2009. Published as Disciplined Agile Delivery (DAD) in book form in 2012, expanded to the broader Disciplined Agile (DA) toolkit covering enterprise-level concerns. Acquired by the Project Management Institute (PMI) in 2019, giving PMI a credible agile asset and giving DA enterprise distribution. Choose Your WoW! (Ambler and Lines, current edition under PMI) is the canonical text.
Scale assumption: A toolkit rather than a single prescribed framework. DA supports four lifecycles within one programme: agile (Scrum-based), lean (continuous-flow), exploratory (lean-startup), and traditional (plan-driven). Teams pick the lifecycle that fits their context and the toolkit guides the choice with goal diagrams.
Prescriptive vs flexible: Choice-driven, goal-oriented. Rather than prescribing specific practices, DA defines process goals (“Form Team”, “Address Risk”, “Coordinate Activities”) and presents the practice options for achieving each goal with their trade-offs. The framework is intentionally agnostic about which practice is right, demanding instead that teams choose explicitly.
Governance shape: Pluralistic by design. The toolkit accommodates traditional and agile delivery in the same programme — a deliberate concession to enterprises with regulated workstreams, vendor-managed projects, and pure-agile product teams running alongside each other.
Software-engineering depth: Broad rather than deep. The toolkit includes DevOps, security, architecture, data management and operations as named goal areas. The trade-off is that DA covers more topics than any single framework but goes less deep on the engineering practices within each.
Where it shines: Organisations with mixed delivery contexts — some teams need plan-driven discipline, others run lean-startup experiments, others ship product on Scrum, all under one programme. PMI-aligned governance environments where PMP-trained programme managers need a path to agile that respects their existing certifications. Post-merger integrations where two delivery cultures must coexist without one being subordinated.
Where it gets misapplied: Small organisations overwhelmed by the toolkit's breadth, who would have been better served by a single prescribed framework. Organisations that read “PMI” on the cover and treat DA as “agile for PMP shops” rather than the toolkit it is. Implementations that use DA's flexibility as cover for never making a choice.
Vibe assessment: Under-loved relative to its scope. PMI ownership gave the framework enterprise credibility but slowed community velocity; the conferences are quieter than SAFe's or LeSS's, the open contributions thinner. The framework most likely to do real work in regulated and mixed-portfolio environments, and least likely to be the answer when an organisation says it wants to “go agile”.
Sources: Ambler and Lines, Choose Your WoW! (PMI) · pmi.org/disciplined-agile · PMI DA certification stream (DAC, DASM, DAVSC) · Ambler and Lines, Disciplined Agile Delivery (IBM Press, 2012)
6. Nexus
Author / origin: Ken Schwaber (co-creator of Scrum) and Scrum.org. The Nexus Framework was first released in 2015 and refined in subsequent Nexus Guide updates, with the current version covering Scrum.org's evolved practice. Designed explicitly to be the minimum viable extension of Scrum to multiple teams on a single product.
Scale assumption: Three to nine Scrum teams working from a single Product Backlog on one integrated product increment. Above nine teams the framework's authors recommend either restructuring into multiple Nexus instances or considering a different framework.
Prescriptive vs flexible: Narrow in scope, prescriptive within that scope. Nexus adds only what is strictly needed to make multi-team Scrum work: a Nexus Integration Team (a working unit, not a separate role hierarchy), Nexus-level events that bracket the team-level Scrum events, and a Nexus Sprint Goal that holds the increment together. Nothing else changes.
Governance shape: Integration-team-centric. The Nexus Integration Team is accountable for the integrated increment and for coaching Scrum Teams on the engineering practices that make integration possible. Cross-team dependencies are surfaced and addressed in Nexus Sprint Planning rather than left to ad-hoc coordination.
Software-engineering depth: Explicit on integration discipline. The Definition of Done at the Nexus level forces engineering practices — continuous integration, integration testing, shared tooling — that are easy to skip at the team level. In practice this is where Nexus delivers its value: by making integration discipline a structural requirement, not a coaching aspiration.
Where it shines: Single-product organisations with three to nine teams that already practice Scrum effectively and want the minimum process change required to scale. Engineering-led product organisations committed to the Scrum.org ecosystem. Implementations that prefer one well-integrated framework over a portfolio overlay.
Where it gets misapplied: Organisations at ten or more teams that adopt Nexus because they were already running it at nine and could not bring themselves to switch. Organisations with weak Scrum foundations at the team level, where Nexus simply lifts the existing dysfunctions to a higher coordination layer. Multi-product portfolios that should not have been forced onto a single backlog.
Vibe assessment: The “Scrum, just a bit bigger” option. Lower brand surface than SAFe or LeSS, with a smaller external consultant ecosystem. Cleanest path for organisations already in the Scrum.org training stream who want to scale without rebranding. The framework most often forgotten in framework debates because it does not try to win that debate — it tries to keep being Scrum.
Sources: Schwaber and Scrum.org, The Nexus Guide · scrum.org/resources/nexus-guide · Scrum.org Scaled Professional Scrum (SPS) certification · Scrum.org community case studies
7. Kanban Maturity Model (KMM)
Author / origin: David J. Anderson and Teodora Bozheva, Kanban Maturity Model (Lean Kanban Inc., 2018; subsequent revisions). Anderson is also the author of the foundational Kanban book (2010) that established the Kanban Method in software delivery. Distributed through Kanban University (formerly Lean Kanban University) and the Mauvius Group.
Scale assumption: Applies at team, service-delivery, and enterprise levels. Maturity is staged 0 through 6 (seven stages: Oblivious, Emerging, Defined, Managed, Established, Optimising, Congruent), each level adding practices that build on the previous. The model is explicit about not requiring a team-structure reorganisation to start — an organisation can adopt KMM without dismantling its existing org chart.
Prescriptive vs flexible: A practice catalogue organised by maturity level, not a single prescribed process. The framework's central premise — “start with what you do now; agree to pursue evolutionary change” — treats the existing organisation as the starting point and lets practice adoption follow capability.
Governance shape: Flow-based and service-oriented. Work is treated as a stream of demand against capacity. Governance shifts from project-and-resource thinking toward service delivery, classes of service, and explicit policies for handling different demand types. No required role changes — the existing organisational structure remains in place.
Software-engineering depth: Agnostic. KMM focuses on workflow, demand management, classes of service and policies; it is not opinionated about specific engineering practices. Engineering-rich teams keep their practices; engineering-light teams are not forced into them by the framework.
Where it shines: Operations-heavy and service-delivery organisations — IT operations, infrastructure teams, support, regulated-process work. Organisations where reorganisation is politically or practically impossible. Mature engineering shops that have already rejected Scrum's ceremony density and want structural improvement without losing their existing flow.
Where it gets misapplied: Product-org buyers expecting team-structure prescriptions, who find KMM's evolutionary stance frustrating. Implementations that reduce the framework to “put a Kanban board on the wall” without adopting WIP limits, classes of service, or the maturity-staged practice progression. Organisations that adopt KMM as an excuse to avoid the harder organisational work.
Vibe assessment: The framework consultants reach for when an organisation has rejected Scrum but still needs structural improvement. Quiet, durable adoption pattern: fewer flagship case studies than SAFe, lower brand surface, but high retention once adopted. The most under-discussed framework in this comparison and one of the most useful in the right organisational context.
Sources: Anderson and Bozheva, Kanban Maturity Model (Lean Kanban Inc., 2018) · kanbanmaturitymodel.com · Kanban University certification (KMP, KCP) · Anderson, Kanban: Successful Evolutionary Change for Your Technology Business (Blue Hole Press, 2010)
8. FAST — Fluid Agile Scaling Technology
Author / origin: Ron Quartel, originally formulated in 2017 from his earlier work with self-organising agile teams at scale. Documented in the FAST Guide, refined through subsequent revisions and community contributions on fastagile.io. The framework draws on Open Space Technology principles for self-organisation and applies them inside a software-delivery context.
Scale assumption: A “tribe” of typically 30-150 people. Crucially, teams are not fixed. At the start of each short iteration (typically two days to one week), tribe members self-organise around the work items they care about, form teams for that iteration, and disband at the end. Fixed Scrum teams with stable membership do not exist.
Prescriptive vs flexible: Radically flexible. No fixed Scrum Masters. No fixed Product Owners. No fixed team rosters. The structural prescriptions are minimal: a tribe meeting at the start of each cycle, a marketplace where work is offered and taken up, and lightweight work streams to maintain continuity across cycles for longer-running concerns.
Governance shape: Self-organising and market-based. Demand surfaces at the tribe meeting; people choose what to work on; work-stream stewards maintain continuity for items that span multiple cycles. The model relies on collective accountability and transparent surface area rather than named role-based authority.
Software-engineering depth: Assumes a mature engineering culture. No built-in compensation for weak technical foundation. Without trunk-based development, continuous integration, comprehensive test coverage and shared code ownership, the fluid-team model produces chaos rather than autonomy. FAST is unforgiving of engineering shortcuts in a way the more structured frameworks are not.
Where it shines: Technology-mature organisations with high trust, willing to dissolve fixed team identity in favour of fluid collaboration. Research groups, platform-engineering teams, advanced product organisations where the work is intrinsically variable. Organisations where the existing engineering culture is strong enough to absorb the loss of team-level structure.
Where it gets misapplied: Organisations that lack the engineering discipline FAST presumes — without continuous integration and a strong test base, the framework's daily reshuffling becomes daily firefighting. Organisations with external commitments or hard delivery dates that need the predictability fixed teams provide. Programmes with regulatory requirements for named individual accountability.
Vibe assessment: The outlier. Almost unknown to corporate buyers, occasionally cited by senior engineers as the most genuinely-agile of the scaled frameworks. The framework most likely to be brought up in a senior-engineering conversation about “what would actually work if we did not have to fit a procurement template”. Influential well beyond its adoption footprint — ideas from FAST show up in other frameworks' evolution paths.
Sources: Quartel, The FAST Guide (fastagile.io) · fastagile.io · FAST community talks and case studies · Open Space Technology origin material (Owen, 1997)
How the big firms package them
The ten firms below ship agile transformations in volume. Each has a named offering, a packaging story, and (mostly) a named flagship case study. The pattern: a base method (usually SAFe, sometimes LeSS or Spotify-inspired), plus the firm's signature wrappers (named platforms, accelerators, training), plus access to global talent. The differences live in the wrappers.
BCG
Named offering: Agile at Scale, situated under the People & Organization and Business Transformation practices. The signature diagnostic is “Agile Performance Management”.
Methods layered: Spotify-inspired tribe and squad structures form the dominant pattern in BCG's published agile cases. SAFe coordination patterns appear in regulated-industry engagements. BCG's own portfolio-governance overlay sits on top of whichever base method the engagement uses.
Signature IP: BCG Agile Diagnostic, Agile Performance Management framework, the “Build for the Future” benchmark series. BCG X — the merged technology build unit formed in 2022 from BCG GAMMA, BCG Platinion and BCG Digital Ventures — provides the engineering side of large transformations.
Named flagship case: ING Bank's 2015-2018 “Spotify-inspired” transformation is BCG's most-cited public agile case (jointly narrated with McKinsey, whose involvement is also publicly documented). Roche and several large European banks appear in BCG's case-study library.
Training/certification: Internal BCG academies for consultants. No public certification stream. BCG X carries engineering-specific training internally.
Positioning vibe: Strategy-first. Agile is positioned as operating-model transformation owned at C-suite level, with engineering practice as a downstream concern handled by BCG X or by client engineering teams. Conceptually adjacent to BCG's broader “10-20-70” thesis from the AI piece — agile delivers the 70 (people, process, change).
Sources: BCG.com agile-at-scale capability page, Agile Performance Management publications, ING transformation case-study coverage (BCG and third-party). Snapshot date to be pinned during research session; firm pages refresh frequently.
McKinsey & Company
Named offering: Agile transformation under the People & Organizational Performance practice, anchored by the “Five Trademarks of Agile Organizations” diagnostic. Adjacent McKinsey Quarterly and McKinsey Insights publishing serves as the public-facing IP layer.
Methods layered: Spotify-inspired structures appear in McKinsey's published case work. SAFe-pattern coordination in regulated-industry engagements. McKinsey's own organisational-design overlay (Org Health Index, Influence Model) sits across the agile delivery work.
Signature IP: “The five trademarks of agile organizations” (Bazigos, De Smet, Gagnon, 2018) is the dominant published asset — the five being North Star embodied across the organisation, network of empowered teams, rapid decision and learning cycles, dynamic people model, and next-generation enabling technology. Agile Performance Management essays and the Org Health Index agile diagnostic round out the public IP.
Named flagship case: ING Bank's 2015-2018 transformation (publicly co-narrated with BCG). Roche's R&D agile transformation. Multiple Asian and European banking transformations cited in McKinsey Quarterly. The McKinsey-authored ING case is the most-cited agile transformation in business literature.
Training/certification: Internal McKinsey practitioner network. No public certification stream. The McKinsey Forward training programme (broader leadership development) includes agile content.
Positioning vibe: Agile as organisational design problem. Weight on diagnostics, surveys and operating-model change rather than engineering practice. The firm most likely to lead a board-level conversation about agile transformation, and the firm least likely to be in the room when the CI pipeline gets configured.
Sources: Bazigos, De Smet, Gagnon, “The five trademarks of agile organizations” (McKinsey, 2018) · McKinsey Quarterly agile pieces (Aghina, De Smet, others, multiple years) · McKinsey ING Bank case studies. Snapshot date to pin during research.
Deloitte
Named offering: Agile@Scale (also referenced as “Agile at Scale” in various Deloitte properties), supported by an Agile Maturity Model diagnostic and the Agile Transformation Playbook.
Methods layered: SAFe is the dominant base method — Deloitte is a Scaled Agile Inc. Global Transformation Partner at the top tier of the partner ecosystem. LeSS and Spotify-inspired structures appear where context fits, particularly in product-led engagements. Scrum at team level throughout.
Signature IP: Agile Maturity Model, Agile Transformation Playbook, SAFe partnership accelerators, Agile@Scale capability pages. Adjacent: the Trustworthy AI framework (seven dimensions, from the AI piece) shares governance DNA with Deloitte's agile-governance approach.
Named flagship case: Public-sector and financial-services transformations across US, UK and European geographies. Specific named cases vary by Deloitte member firm; flagship to confirm during snapshot.
Training/certification: Among the largest SAFe-certified consultant benches in the industry. Internal Deloitte Agile Academy. PMI Disciplined Agile partnership for hybrid programmes.
Positioning vibe: SAFe-aligned, governance-friendly, audit-ready. The firm to retain when regulators are in the room and the transformation needs to survive a compliance review. Less product-engineering depth than Capgemini or IBM; more programme-governance depth than McKinsey or Bain.
Sources: Deloitte.com Agile@Scale capability pages · Scaled Agile Inc. Global Transformation Partner directory · Deloitte Insights agile publications · regional Agile Maturity Model write-ups. Snapshot date to pin during research.
EY (and EY-Parthenon)
Named offering: Business Agility (also referenced as “Agile Business Reinvention” in various EY properties), positioned within the broader Transformation Realized framework.
Methods layered: SAFe-aligned in the majority of public cases. Scrum at team level. EY's “transformation activation” change-management overlay sits across the agile delivery.
Signature IP: Transformation Realized framework (EY's overarching transformation methodology, into which Business Agility plugs as the delivery model). EY Wavespace facilitation studios for workshops and PI-style planning events. Adjacent: EY.ai and the EYQ Agentic Platform (from the AI piece) — agile delivery on top of EY's regulated-industry AI stack.
Named flagship case: Regulated-industry transformations (financial services, government, tax). Specific named cases vary by EY member firm and engagement confidentiality; flagship to confirm during snapshot.
Training/certification: SAFe partner. Internal EY Wavespace facilitation programme. EY-specific change-management certifications.
Positioning vibe: Transformation-and-change-heavy. Agile lives inside a broader change story rather than standing alone. Less software-engineering depth than Capgemini or IBM; more change-management and stakeholder-management depth than most peers. The firm to retain when the agile delivery is the means and the regulated-industry restructuring is the end.
Sources: EY.com Business Agility and Transformation Realized capability pages · EY Wavespace publications · EY-Parthenon strategy-and-transformation insights. Snapshot date to pin during research.
PwC
Named offering: Agile transformation positioned under the Business Transformation practice, frequently bundled with Digital Transformation engagements. PwC's BXT (Business-Experience-Technology) operating model sits as the overarching transformation architecture.
Methods layered: SAFe and Scrum@Scale appear in PwC's published case work. Scrum at team level. The BXT model wraps whichever base agile method the engagement uses.
Signature IP: BXT operating model (PwC's most-cited transformation IP — argues that Business, Experience and Technology have to be designed and led together rather than handed off). Digital Fitness assessment. Adjacent: ChatPwC, the ~200,000-seat ChatGPT Enterprise rollout (from the AI piece), is the most-scaled internal GenAI tool of any firm in this comparison — agile delivery teams ship onto a GenAI-saturated workplace.
Named flagship case: Financial-services agile rollouts across US, UK and European markets. Flagship to confirm during snapshot; PwC's agile case publication is lower-volume than the Big Four peers.
Training/certification: SAFe-certified bench. PwC Academy programmes. Internal BXT facilitator training.
Positioning vibe: Change-management-led. Agile presented as enterprise behavioural transformation rather than software-engineering practice. Less branded agile-specific methodology than Deloitte or Accenture — PwC's agile work happens inside Business Transformation rather than standing as its own offering.
Sources: PwC.com Business Transformation and Digital Transformation capability pages · BXT methodology publications · PwC Global CEO Survey (agile-related findings). Snapshot date to pin during research.
KPMG
Named offering: Agile transformation situated within the Connected Enterprise capability framework, often paired with KPMG Powered Enterprise (KPMG's SaaS-accelerated transformation methodology).
Methods layered: SAFe is the dominant base method in KPMG's published agile engagements. Scrum at team level. Connected Enterprise wraps the agile delivery with KPMG's capability-model assessment.
Signature IP: Connected Enterprise (eight functional and customer capabilities arranged for end-to-end transformation), Powered Enterprise (pre-configured SaaS solution accelerators for ERP, HR, finance and operations), KPMG Lakehouse (the firm's flagship training and innovation campus). Adjacent: the Trusted AI framework (10 pillars, from the AI piece) shares governance DNA with KPMG's agile-governance approach.
Named flagship case: Financial-services and public-sector transformations across UK, US and Asia-Pacific. Specific named flagship case to confirm during snapshot.
Training/certification: SAFe partner. KPMG Lakehouse (Orlando, FL and other campuses) provides immersive training for both consultants and client teams.
Positioning vibe: Capability-model-led. Agile sits inside a broader capability framework rather than standing as the centrepiece. KPMG's audit DNA carries into agile-governance design — the firm to retain when the agile transformation must produce traceable, auditable governance artefacts. ISO/IEC 42001 first-claim adjacency (from the AI piece) reinforces the governance posture.
Sources: KPMG.com agile-transformation and Connected Enterprise capability pages · KPMG Powered Enterprise publications · KPMG Lakehouse programme overview. Snapshot date to pin during research.
Accenture
Named offering: Business Agility within the Strategy & Consulting practice; Agile Engineering Studios within the Technology practice; agile-and-DevOps services within Operations. Accenture's agile capability spans three of the firm's four service lines.
Methods layered: SAFe is the dominant base method, with Accenture among the largest SAFe Global Transformation Partners. Spotify-inspired structures appear in tech-native engagements. Scrum at team level throughout. The myConcerto industry solution overlay sits on top of the agile delivery.
Signature IP: myConcerto (industry-aligned solutions accelerator), Agile Engineering Studios (regional engineering hubs), ADM and ADMnext (Application Development & Maintenance — the engineering-services delivery overlay; ADMnext is the rebranded next-generation version). Adjacent: AI Refinery and the $3B AI investment (from the AI piece) — agile teams deliver onto Refinery; the Accenture-NVIDIA Business Group is the most branded hyperscaler alliance in consulting.
Named flagship case: Multiple Fortune 500 transformations cited publicly across financial services, retail, healthcare and industrial sectors. Specific named flagship to confirm during snapshot; Accenture's case-study volume is among the highest in the industry.
Training/certification: Plausibly the largest SAFe-certified consultant bench in any firm (tens of thousands of certifications across the global workforce). Accenture Academy. Agile Engineering Studios as the bench-development engine.
Positioning vibe: Scale and execution. Agile sits inside Accenture's broader engineering-services offering rather than as a stand-alone transformation. The firm to retain when the transformation requires global delivery, multi-vendor coordination, and a SAFe-certified bench available on call. Less senior-partner-led narrative than McKinsey or Bain; more execution-engine depth than any peer.
Sources: Accenture.com Business Agility, Agile Engineering Studios and myConcerto capability pages · Scaled Agile Global Transformation Partner directory · ADM and ADMnext publications · Accenture-NVIDIA Business Group announcements. Snapshot date to pin during research.
Bain & Company
Named offering: Agile Innovation (Bain's most distinctive published agile offering), supported by the Bain Agile Innovation Network and the Agile Enterprise diagnostic at portfolio level.
Methods layered: Scrum at team level. Bain's own Agile Enterprise diagnostic at portfolio level. Less framework-prescriptive than the Big Four; Bain works at the strategic and operating-model layer and lets the chosen team-level framework adjust to the engagement.
Signature IP: Darrell Rigby (Bain partner, now retired but with continuing thought-leadership presence) co-authored Doing Agile Right (Harvard Business Review Press, 2020) — the most-published Bain agile asset. Earlier HBR articles include “Embracing Agile” (2016), “Agile at Scale” (2018) and “The Agile C-Suite” (2020). Adjacent: Sage (internal GPT-4-based tool, from the AI piece) and the OpenAI alliance — agile teams ship co-designed AI work on top of branded alliance assets.
Named flagship case: John Deere (manufacturing agile, cited extensively by Rigby), Bosch (industrial agile transformation), plus multiple cases in the Rigby HBR catalogue. The published case base is unusually thorough for a strategy firm.
Training/certification: Internal Bain Agile Innovation Practice. No public certification stream. The Rigby book and HBR articles function as Bain's external knowledge transfer.
Positioning vibe: Agile as innovation discipline rather than IT delivery method. Senior-partner-led narrative. The firm most likely to be in the room when an industrial manufacturer wants to introduce agile into product development without restructuring IT delivery. Less ceremony, more strategy.
Sources: Bain.com Agile Innovation capability pages · Rigby, Sutherland and Takeuchi, Doing Agile Right (HBR Press, 2020) · Rigby et al., HBR articles 2016-2020 · Bain Technology Report (annual). Snapshot date to pin during research.
Capgemini
Named offering: ADMnext (Application Development & Maintenance, agile- and DevOps-native — Capgemini's flagship engineering-services platform), supported by Agile and Scaled Agile services and the Capgemini Agile Innovation Centers.
Methods layered: SAFe is the dominant base method — Capgemini is a Scaled Agile Global Transformation Partner. Scrum, Kanban and DevOps are integrated rather than layered separately; the engineering practice and the agile practice arrive together.
Signature IP: ADMnext platform (the most-cited engineering-services delivery asset in this comparison), Capgemini Agile Innovation Centers (regional engineering studios). Adjacent: the Resonance AI Framework (from the AI piece) sits on top of the engineering platform; Capgemini's Google Cloud Partner of the Year 2025 status reinforces the engineering-led tilt.
Named flagship case: European banking, automotive and energy transformations. Mercedes-Benz, BNP Paribas and several large European retailers commonly cited. Specific flagship to confirm during snapshot; Capgemini's case library is heavily European-centric and substantively engineering-led.
Training/certification: Among the largest SAFe-certified benches outside Accenture. Capgemini University (the firm's flagship training campus, France). Internal ADMnext practitioner certification.
Positioning vibe: Engineering-led. The firm most likely to be in the room when the agile transformation is inseparable from a platform-engineering, DevOps or cloud-modernisation programme. Strong European brand authority. Less senior-partner narrative than McKinsey or Bain; more delivery-engineering depth than Deloitte or KPMG.
Sources: Capgemini.com ADMnext, agile services and Agile Innovation Center pages · Scaled Agile Global Transformation Partner directory · Capgemini Research Institute (CRI) publications. Snapshot date to pin during research.
IBM Consulting
Named offering: IBM Garage Method (the firm's canonical agile-plus-engineering delivery methodology), wrapped by Enterprise Design Thinking at the front end and SAFe-aligned coordination at scale. Delivered through IBM Garage locations (physical and virtual studios).
Methods layered: SAFe at programme level — IBM is a SAFe Global Transformation Partner. Scrum at team level. Enterprise Design Thinking on the front of the loop. The Garage Method integrates these into a single Discover-Envision-Develop-Reason-Operate-Culture cycle.
Signature IP: IBM Garage Method — the heritage IP that most distinguishes IBM from the Big Four. Enterprise Design Thinking (IBM's design-led problem-framing approach). Historical lineage to the Rational Unified Process (RUP), IBM's original heavyweight iterative methodology acquired with Rational Software in 2003. Adjacent: IBM Consulting Advantage and watsonx (from the AI piece) — agile delivery teams ship onto the Advantage platform and watsonx model stack.
Named flagship case: American Airlines (Garage-led transformation, publicly documented), USAA (financial-services Garage engagement), Travelport, multiple banking transformations. The Garage Method playbook contains substantive case material.
Training/certification: IBM Skills Academy. SAFe partner. Internal Garage Method certification stream for IBM consultants. Enterprise Design Thinking certification.
Positioning vibe: Design-thinking-to-engineering integrated. The firm most likely to be in the room when the engagement starts with a design-led problem-framing exercise and ends with platform-engineering delivery. Heavy on assets (Garage Method, watsonx, Enterprise Design Thinking) rather than ceremony. The clearest engineering-and-design lineage of any firm in this comparison.
Sources: IBM.com/garage capability pages · IBM Garage Method playbook (ibm.com/cloud/architecture or successor URL) · Enterprise Design Thinking pages · IBM Consulting agile and transformation publications. Snapshot date to pin during research.
The master comparison table
The table below is the reference asset. It cross-cuts the eight frameworks against eight comparison dimensions, with the firms that most actively package each framework called out in the rightmost column.
| Framework | Primary author | Scale assumption | Prescriptive level | Governance shape | Engineering depth | Certification ecosystem | Most active firm packagers |
|---|---|---|---|---|---|---|---|
| SAFe | Dean Leffingwell (Scaled Agile Inc.) | 50-125 per ART; portfolio > 1,000 | High | Hierarchical (Portfolio → Team) | DevOps + XP named | 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) | Low-medium | Flat (one PO) | High (technical excellence) | CLP, CLT (LeSS Company) | Smaller specialists; partial use by McKinsey, Bain |
| Scrum@Scale | Jeff Sutherland (Scrum Inc.) | Modular; SoS structure | Low (modular core) | Two-cycle (PO + SM) | Medium (training-dependent) | SSM / SPS (Scrum Inc.) | BCG (selective); independent consultants |
| Spotify Model | Henrik Kniberg / Anders Ivarsson | Tribes / Squads (no fixed size) | Cultural, not structural | Matrix (Tribe × Chapter) | Implied high (Spotify engineering) | None official | BCG (ING) · McKinsey · digital-native consultancies |
| Disciplined Agile (DAD) | Scott Ambler / Mark Lines (PMI) | Toolkit; lifecycle-agnostic | Choice-driven (goal-oriented) | Pluralistic (agile/lean/plan-driven) | Broad (DevOps, security, architecture) | DAC, DASM, DAVSC (PMI) | PMI-aligned firms; IBM legacy |
| Nexus | Ken Schwaber (Scrum.org) | 3-9 Scrum teams, one product | Low (Scrum extension) | Integration-team-centric | Medium (integration discipline) | SPS, NXTC (Scrum.org) | Scrum.org-aligned consultancies; partial Accenture |
| Kanban Maturity Model (KMM) | David J. Anderson (Mauvius Group) | Team to enterprise, maturity stages 0-7 | Practice catalog | Flow-based, evolutionary | Agnostic | KMP, KCP (Kanban University) | Operations-heavy firms; partial Capgemini |
| FAST | Ron Quartel | Tribe of 30-150, dynamic teams | Radically flexible | Tribe-meeting / marketplace | High (assumes mature practice) | None mainstream | Specialist coaches; rarely big-firm |
What is actually different
- Only three frameworks publish a numbered methodology you can implement without a consultant. SAFe has roles, ceremonies, artefacts and a Continuous Delivery Pipeline a transformation team can read and execute. LeSS has the published rules of multi-team Scrum on one product. Scrum@Scale has the SoS and the two coordination cycles. The other five — Spotify, DAD, Nexus, KMM, FAST — are either toolkits, snapshots, or minimal extensions that need either an experienced practitioner or a substantial existing context to land. This is not a quality judgement: toolkits and snapshots are sometimes the right answer. It is a buyer-clarity judgement: only three of the eight frameworks reduce the consultant dependency that the framework was supposed to reduce.
- Software-engineering depth is the cleanest dividing line in the field. LeSS and FAST presume mature engineering practice and are unforgiving of its absence. SAFe and Nexus name engineering practices explicitly in their guides but rely on the implementer to bring them. Spotify, DAD, KMM and Scrum@Scale are largely agnostic on engineering practice. A buyer who knows their organisation's engineering culture honestly can map this column straight onto framework fit; a buyer who does not know will adopt a framework that exposes the gap painfully.
- Only two frameworks have major-firm-grade certification programmes. SAFe (Scaled Agile Inc., dominant, multiple role-aligned certifications, large partner ecosystem) and Disciplined Agile (PMI-owned since 2019, integrated with the PMP credential). The other six have certifications — LeSS Company, Scrum.org Nexus, Scrum Inc. Scrum@Scale, Kanban University KMP, fastagile.io community — but the volume and consulting-firm penetration is an order of magnitude lower. This drives a follow-on effect that buyers rarely see: the SAFe-saturated talent market means SAFe expertise is genuinely available on call, in a way that is not true for LeSS or FAST at enterprise scale.
- The Spotify Model is the most cited and least implemented artefact in the field. It is not a framework. The original 2012 paper described what Spotify was doing at the time; the subsequent retrospectives (Sundén 2017, others) are explicit that Spotify itself moved past those diagrams within a year or two. Yet every consulting firm in this comparison uses some version of “tribes” and “squads” in their agile collateral, and a substantial fraction of public agile transformations cite Spotify as the model. The vocabulary travels; the engineering culture, the product-management investment and the platform infrastructure that made the Spotify structure work do not.
- FAST and Kanban Maturity Model are the only frameworks that do not require a team-structure reorganisation. Every other framework in this list assumes some form of explicit team configuration, whether prescribed (SAFe ARTs, LeSS feature teams, Nexus Scrum teams) or descriptive (Spotify squads). KMM works with the existing structure; FAST dissolves stable structure entirely in favour of fluid daily formation. For organisations where reorganisation is politically or practically impossible — post-merger contexts, regulated structures, organisations recovering from a previous failed transformation — this is the cleanest dividing line in the field.
- Three firms publish substantive methodology IP that does not just relabel SAFe. Bain (Rigby's Doing Agile Right book and the HBR article series) has a published methodology with its own theory of where agile fits in a corporate strategy. McKinsey (the Five Trademarks of Agile Organizations) has a board-room diagnostic that operates above any framework. IBM (the Garage Method and Enterprise Design Thinking, with Rational Unified Process heritage) has the longest-running published delivery methodology in the field. The other seven firms operate substantively as SAFe partners with branded wrappers, even where their public collateral references other methods.
What is mostly branding
- Most “agile transformation offerings” from the Big Four are SAFe with a firm-branded wrapper. Strip the branded diagnostic, the firm-coloured PI Planning template and the proprietary maturity model, and the base method underneath is SAFe in seven of the ten firms in this piece (the exceptions being Bain, McKinsey's diagnostic-led narrative, and IBM's Garage Method). This is not a criticism of SAFe and not a criticism of the firms — SAFe earned its market share — but a buyer should know whether the firm's IP is the wrapper or the base.
- “Tribes and squads” has become a vocabulary, not a method. Almost every firm in this comparison uses Spotify-derived language in their agile collateral. Almost none of them deliver the engineering culture, the product-management discipline, or the internal-platform investment that made the Spotify structure work. If a firm uses the Spotify vocabulary without naming what they will do about engineering practices, internal developer platforms and the product-management operating model, treat the vocabulary as branding.
- Agile maturity models are mostly self-similar. Four to five levels. The same handful of axes — usually some combination of process, people, technology, culture and customer outcomes. Compare any three firms' agile maturity models side by side and the structural similarity is striking. The maturity model serves a specific purpose — it makes the engagement legible to a steering committee — but it is rarely the firm's actual delivery IP. The IP is in the consultants who walk the organisation through the levels.
- SAFe certification volume signals less than it used to. The certification stream is large, the mass-training pipeline is mature, and the tenure-of-a-fresh-certification is not what it was a decade ago. A SAFe-certified consultant count tells you how many people the firm has put through a course, not how many have delivered an agile transformation that survived a five-year check-in. Ask for the delivered-engagement count, not the certification count.
- Most “flagship cases” do not survive an honest five-year check-in. The most-cited transformation in the modern era — ING Bank's Spotify-inspired restructuring of 2015-2018, narrated by BCG and McKinsey — has substantially evolved in the years since, and the current ING organisation looks meaningfully different from the 2017 diagram. This pattern is not unique to ING; it is the rule, not the exception. A firm's published flagship case is a snapshot of one moment in a long programme. Ask what the case looks like today, not what the deck said it would look like.
The 2026 reality: AI, smaller teams, platform engineering
Every framework in this comparison was designed before generative AI changed the size of the team that ships a given workload. The implications are not yet showing up in the framework guides — SAFe 6.0 makes only modest gestures toward AI, the LeSS guide is silent, the Spotify model retrospectives predate the current AI moment — but they are visible in 2026 transformations.
Generative AI compresses team size. A product workload that needed a tribe of eighty engineers, designers and product managers in 2018 is, in many cases, deliverable by eight to fifteen people in 2026, using AI-assisted development, AI-generated test coverage and AI-augmented design. The frameworks built for headcount-heavy programmes — SAFe at the ART level in particular, with its 50-125 person assumption and PI Planning logistics — are under structural pressure. The frameworks that scale down cleanly (FAST, KMM, Nexus and LeSS at the small end of its range) are gaining quiet ground.
Platform engineering is replacing some coordination ceremonies. Internal developer platforms now do the cross-team work that previously sat in Scrum-of-Scrums meetings, PI Planning rooms and integration-team rituals. When the platform absorbs the coordination, the framework needs less of it. The agile frameworks most under pressure are those whose value proposition was substantially “coordination ceremonies and shared cadence”. The frameworks most reinforced are those whose value proposition was substantially “engineering practice and flow”.
Remote-first changes the economics of co-located ceremonies. PI Planning over Zoom is not what PI Planning was in a conference centre with eighty people on sticky notes. The frameworks that depended on a particular co-located ritual quality are softer than they were; the frameworks that worked through any communication medium (KMM's flow boards, Nexus's integration discipline) have held up better. This is not a verdict on remote work; it is an observation about which frameworks priced their ceremonies into the value proposition.
The decision rule has shifted. The framework-selection question in 2018 was “which framework scales?”. In 2026 it is closer to “which framework survives a fifty-percent headcount cut without losing identity?”. SAFe-at-Portfolio survives the cut by reducing the number of ARTs, but a SAFe ART itself is awkward at less than fifty people. LeSS scales down to two teams cleanly. KMM does not require headcount-defined structure at all. Spotify-style tribes lose their identity when the tribe collapses to one squad.
This shift connects directly to the buyer's question we examined in the companion piece, The Big Consulting AI Frameworks, Compared. AI is not just a technology to deploy; it is a change in the unit economics of software delivery. The agile framework that fits an AI-saturated 2026 organisation is rarely the same agile framework that fit the same organisation in 2018, even when nothing else about the work has changed. The frameworks that look strongest in this environment are the ones built around flow and engineering practice; the frameworks that look weakest are the ones built around headcount-heavy coordination.
How to read this if you're the buyer
If you're a CEO, board member, transformation officer or PE investor, the framework debate is almost never the most useful place to spend your decision energy. The five scenarios below cover most of what actually shows up on agile-transformation proposals; pick the scenario that fits, look at what the framework match tells you, and use the three questions at the end to read any firm's pitch in five minutes.
Scenario 1 — Mid-market scaling (300-2,000 employees, growing fast). The right answer is rarely SAFe; it is too heavy for the size and the certification ecosystem is calibrated for larger enterprises. Look at Scrum@Scale or LeSS at the small end of its range. The firm choice is typically a specialist agile consultancy or a senior independent practitioner; the Big Four are calibrated for larger engagements and the cost of access is high relative to the value you will extract at this size.
Scenario 2 — Regulated industry (banking, pharma, regulated utilities, defence). SAFe wins on audit-friendliness by a wide margin — named roles, traceable artefacts, certified consultants who pass procurement filters. The firm choice is Deloitte, Accenture, Capgemini, KPMG or EY, depending on regional presence and existing relationship. The trade-off you are making is engineering-practice depth in return for governance legibility; budget separately to fill the engineering gap.
Scenario 3 — Post-merger integration. Two delivery cultures, often two delivery toolchains, often two existing agile flavours that disagree. DAD's pluralistic lifecycle model fits this pattern better than any single-philosophy framework; KMM works well when reorganisation is politically off the table. PMI-aligned firms or specialist post-merger integration consultancies. Avoid forcing one side onto the other's framework as the integration motion — the political cost rarely justifies the methodological purity.
Scenario 4 — AI-heavy programme. Smaller teams, faster cycles, platform-engineering-dependent. FAST or LeSS at the small end fit better than SAFe; KMM works for the operations side of the same programme. The firm choice overlaps substantially with the AI-consulting decision — see the companion AI piece for that selection. The agile framework is the delivery layer for the AI work; pick it for engineering-practice fit, not for ceremony density.
Scenario 5 — Classic IT-to-product shift. A traditional IT delivery organisation moving to product-led, outcome-oriented teams. Spotify-inspired structures with deep engineering-culture investment are the textbook answer; the textbook is often misread. BCG or McKinsey provide the org-design overlay and the board-level narrative; the engineering work is the hard part and rarely the part the strategy firm is best positioned to deliver. Plan for a second engineering-led engagement — Capgemini or a specialist platform-engineering firm — alongside the strategy work.
Three questions cut through a firm's pitch faster than any scoring matrix:
- “Show me the engineering practice your team will deliver, in detail, on Monday.” If a firm cannot describe their team's engineering practice — trunk-based development, CI configuration, test coverage approach, code-review discipline, platform tooling — in detail, what you are buying is ceremony, not delivery. That is sometimes the right call. Know that it is the call you are making.
- “Show me where your last engagement's structure looks like today.” Frameworks evolve, and the honest answer reveals what survived contact with the organisation. Firms that cannot tell you what their last engagement looks like in 2026 are either uninvolved with post-engagement reality or unwilling to share it. Both are useful signals.
- “Who owns the integration work between teams, and how is it staffed?” Coordination is the real cost of scaled agile. The most common failure pattern is a framework that names the integration role on a slide and leaves it unstaffed in the engagement. Ask who, ask their CV, ask their reporting line. If the answers are vague, the integration is going to be paid for in delivery delays.
Where Consulting Huber fits
Consulting Huber is a practitioner firm, not a Big Four or MBB peer. We do not compete on SAFe-certified bench size, on global delivery footprint, or on the volume of named flagship cases. We compete on the opposite problem: transformation officers, CEOs, boards and PE investors who want the methodology and the engineering discipline of a large firm, delivered directly by senior practitioners, with the capability transferred to the client's own team at the end of the engagement.
That means we will tell you which framework actually fits your organisation's engineering culture rather than which framework our certification stack favours. It means we will work with you to staff the integration role properly rather than naming it on a slide. It means we will let you keep the right to fire us at the end of any cycle, because the model is capability transfer, not platform lock-in.
The companion piece on the AI side — how the same ten firms frame AI and GenAI transformation, with the same buyer's-seat lens — sits at The Big Consulting AI Frameworks, Compared (2026). Our service page on the end-to-end agile work is at Business agility. If you want the AI-and-agile-bridge view of how these two pieces connect for a real programme, the AI value creation playbook is the third corner of the triangle.
Sources consulted
Primary sources — framework canonical texts
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
Primary sources — firm capability pages (snapshot date 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. Specific URLs to be pinned at snapshot.
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. Specific URLs to be pinned at snapshot.
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. Specific URLs to be pinned at snapshot.
EY (and EY-Parthenon)
EY.com Business Agility capability pages · EY Transformation Realized framework pages · EY Wavespace publications · EY-Parthenon strategy and transformation insights. Specific URLs to be pinned at snapshot.
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). Specific URLs to be pinned at snapshot.
KPMG
KPMG.com agile-transformation and Connected Enterprise capability pages · KPMG Powered Enterprise publications · KPMG Lakehouse programme overview · KPMG global advisory transformation insights. Specific URLs to be pinned at snapshot.
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. Specific URLs to be pinned at snapshot.
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). Specific URLs to be pinned at snapshot.
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. Specific URLs to be pinned at snapshot.
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. Specific URLs to be pinned at snapshot.
Third-party benchmarks and 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. Specific URLs to be pinned at snapshot.
Practitioner interviews conducted for this edition
To be added during research: named conversations with framework authors and senior firm practitioners where they consent to attribution. Reference-grade pieces gain materially from one or two on-the-record quotes; outreach is in progress at the snapshot date.
How to cite this article
APA-style:
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/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/agile-consulting-frameworks-compared.html}
}
Snapshot date: 2026-05-14. Annual refresh planned; subsequent editions will preserve the previous edition at a dated URL.
Related: Business agility service · AI frameworks comparison (companion piece) · AI value creation playbook · Case studies · All services