SAFe Principles

25 MIN READ

SAFe Framework Version History

SAFe published six major versions since 2011, yet its ten Lean-Agile principles never moved — here's the version-vs-configuration split that explains why.

Ask a SAFe consultant which version their client runs, and the frank answer is usually two numbers, tracked separately, neither of which is the framework’s ten principles. SAFe Framework Version History looks like a straight timeline from the outside: it isn’t, and the axis most explanations flatten out is the one that actually matters.

SAFe Version History: How Ten Immutable Principles Survived Six Major Framework Releases

Dean Leffingwell, co-founder of Scaled Agile, Inc., defined the ten SAFe Lean-Agile principles as the framework’s constant reasoning layer, and SAFe 6.0 still frames them the same way even though the framework has published six major version numbers, SAFe 1.0 through SAFe 6.0, since 2011. That consistency sits oddly next to a release history this active: six major versions plus a run of point releases (SAFe 4.5, 4.6, 5.1) is not what “immutable” usually looks like next to a product roadmap.

Where Did SAFe’s Six Version Changes Actually Land?

The resolution is that versioning happened at a different layer than the one the principles occupy. SAFe describes its ten principles as universal tenets and economic concepts that inspire and inform the roles and practices built on top of them: not the practices themselves. Every one of the six major releases changed roles, competencies, or configurations layered above that reasoning; none of them rewrote the reasoning. The principles did not move. The structure around them moved six times.

That distinction only holds if two words stop being used interchangeably: version and configuration.

Versions vs. Configurations: The Vocabulary This Article Uses

A version is a numbered framework release, SAFe 1.0 through SAFe 6.0, while a configuration is a deployment-scope choice, such as Essential SAFe or Full SAFe, that can change independently of the version number currently installed.

Version numbers describe when Scaled Agile, Inc. published new guidance. Configuration names describe how much of that guidance an organization actually deploys. An enterprise can sit on SAFe 6.0 guidance while running Essential SAFe, the smallest configuration, for a single Agile Release Train, or it can run Full SAFe, stacking Large Solution and Portfolio layers on top of Essential SAFe for a multi-train, multi-solution enterprise. Both are legitimate SAFe 6.0 deployments; they differ in scope, not in principle set.

The stability shows up in specifics, not just in vocabulary. SAFe’s own definition of an Epic, a large body of work, has not been redefined the way configuration guidance has been redefined across six versions. An Epic Owner working from SAFe 1.0-era guidance and one working from SAFe 6.0 guidance would recognize the same object: a large, cross-cutting body of work sized above what a single team or Program Increment can absorb. What changed around it, which configuration owns it, which role approves it, which competency governs its funding, is a version-layer question, not a principle-layer one. Every section that follows traces what actually changed at that outer layer, version by version, without pretending the inner layer moved with it.

Before SAFe 1.0: The Lean and Agile Lineage Dean Leffingwell Synthesized Into One Framework

SAFe’s lineage runs on two tributaries of very different ages: a lean tributary that traces back roughly a century, and an agile tributary barely a decade old by the time Leffingwell fused them into SAFe 1.0 in 2011. That century-long gap is easy to state and easy to miss the significance of: it means most of what SAFe calls “lean” predates the software industry that eventually adopted it, while almost everything it calls “agile” was still being argued about in mailing lists when SAFe launched.

When Did the Lean Tributary Actually Begin?

The lean lineage is the older, deeper root, and its own historians date it precisely. John Dewey’s 1911 book How We Think is the source Walter Shewhart and W. Edwards Deming drew on to build the Plan-Do-Check-Act cycle: the reasoning loop that underpins SAFe’s own inspect-and-adapt rhythm decades later. James Womack of the Lean Enterprise Institute dates the world’s first continuous-flow assembly line to Henry Ford’s Highland Park plant, spring 1914: a site he calls the most important industrial and economic leap in human history, now empty and uncommemorated. Nine decades separate Dewey’s book from SAFe 1.0; the assembly line at Highland Park predates it by ninety-seven years.

What Did the Agile Landscape Look Like Before SAFe Existed?

The agile lineage is far younger, and Martin Fowler’s own account of it is precise about how young. Fowler’s essay “The New Methodology”, first published July 2000 and substantially rewritten in December 2005, names the landscape Leffingwell was actually drawing from when there was no dominant scaling framework yet: the Agile Manifesto, Extreme Programming, Scrum, Crystal, Lean Development, and the Rational Unified Process. The Agile Alliance’s own practices timeline places the Waterfall Model as the rigid predecessor both lineages were reacting against, with Agile Software Development Methodology formally named in 2001; roughly a decade before SAFe 1.0, not a century.

The Lean Lineage: From Dewey’s 1911 Method to Toyota

Dewey’s 1911 method of structured reflection became, through Shewhart and Deming, the Plan-Do-Check-Act cycle that shows up in SAFe’s Inspect and Adapt events nearly a century later, and tracing that chain explains why SAFe’s flow vocabulary reads as older than software itself.

The chain does not skip from Dewey straight to Toyota. It runs through a wartime training program most SAFe practitioners have never heard of, and that program is where the reasoning became teachable at scale rather than staying a philosopher’s method.

Training Within Industry’s 1944 Shop-Floor Exercises

Training Within Industry (TWI) ran structured role-play exercises on U.S. shop floors by 1944, turning subject-matter experts into coaches capable of transferring skill rapidly during wartime production: a training model built directly on the Dewey-Shewhart reasoning chain rather than invented from scratch.

The urgency behind TWI matters for understanding why it worked: major portions of the American workforce were shipping off to fight, and the remaining workers needed new skills fast, with no time for slow apprenticeship. TWI’s answer was a repeatable coaching method rather than a one-off training push, which is precisely why it endures past the war and traveled somewhere the original developers never planned for.

Postwar Transplantation Into Toyota Production System

After World War II, the U.S. Occupation Authority introduced Training Within Industry into Japan to help rebuild collapsed production capacity, and that transplanted program is the direct lineage feeding Toyota Production System thinking: the system SAFe’s own flow principles ultimately draw from.

Japanese industrialists absorbed TWI with an intensity that reshaped their own manufacturing philosophy, because it offered something rare: a method for rapidly raising skill without sacrificing coherence across many workers doing interdependent work. Toyota Production System inherited that discipline directly. By the time Leffingwell was assembling SAFe’s principles more than sixty years later, the reasoning chain from Dewey to Toyota had already been tested at national-recovery scale; SAFe imported a lineage with a track record, not a new theory needing to demonstrate itself.

The Agile Lineage: What Fowler’s 2000-2005 Essay Documents

Fowler’s essay documents agile methods as a reaction to the rigid, document-heavy Waterfall Model, cataloging the Agile Manifesto alongside Extreme Programming, Scrum, Crystal, Lean Development, and the Rational Unified Process as the live methodology landscape circulating in the early 2000s.

What Fowler’s account makes visible is how contested and unsettled that landscape still was less than a decade before Leffingwell needed to scale it. There was no single dominant scaling answer for Fowler to point readers toward; just competing flavors, each solving part of the coordination problem Leffingwell would later need to solve at enterprise scale. The Agile Manifesto itself, dated 2001, is the youngest tributary in SAFe’s entire ancestry: roughly a century younger than Dewey’s method, and barely a decade old by the time SAFe 1.0 shipped. That age gap is why SAFe’s economic and flow vocabulary reads as more mature than its team-level agile vocabulary: one tributary had decades to demonstrate itself in factories before software ever touched it, and the other was still being written down.

SAFe 1.0 Through 3.0 (2011-2014): The Founding Versions That Established the Agile Release Train

SAFe 1.0 launched in 2011 as Dean Leffingwell’s first published scaling framework, introducing the Agile Release Train as the mechanism for coordinating multiple agile teams around a shared Program Increment cadence; and SAFe 2.0 and SAFe 3.0 extended portfolio and program layers on top of that same mechanism without touching the founding principle set. The Agile Release Train, not a new principle, is what SAFe 1.0 actually shipped.

What’s easy to miss is where the mechanism’s economic logic came from: it wasn’t invented inside SAFe at all.

The Agile Release Train: SAFe 1.0’s Core Scaling Mechanism

The Agile Release Train coordinates multiple agile teams around a shared Program Increment, giving teams that build interdependent parts of a system a common planning and delivery cadence instead of leaving their release timing to chance.

Before the ART, scaling agile past a single team meant either forcing every team onto identical sprint boundaries with no shared integration point, or leaving cross-team dependencies to informal coordination that broke down as headcount grew. The ART solved this by giving multiple teams, Leffingwell’s 2011 guidance describes five to twelve, a fixed planning event and a shared increment boundary, so dependencies get surfaced and sequenced together rather than discovered late. SAFe 2.0 and 3.0 then added portfolio and large-solution layers that let multiple ARTs coordinate with each other, but the founding mechanism, one train, one cadence, one planning event, stayed the coordination unit underneath every later expansion. That single-train mechanic is also what became Essential SAFe once later versions needed a name for the smallest legitimate deployment.

Cost of Delay and WSJF: Reinertsen’s Flow Research Made Operational

Cost of Delay and Weighted Shortest Job First turned SAFe’s “take an economic view” principle from a slogan into a repeatable prioritization mechanic, and both concepts came directly from Don Reinertsen’s pre-existing research on product development flow rather than from anything original to SAFe.

Reinertsen’s queueing-theory work on flow and batch size predates SAFe 1.0, and Leffingwell built the founding versions’ prioritization guidance directly on it rather than inventing a new economic model. WSJF divides the Cost of Delay of a piece of work by its job size, producing a ranking that favors small, high-cost-of-delay items over large, low-urgency ones: the arithmetic reason SAFe consistently pushes teams toward smaller batches. Without Reinertsen’s prior research, “take an economic view” would have stayed the kind of principle every framework claims and few operationalize; with it, the founding versions gave portfolio and program teams an actual ranking formula, not just a value statement.

Essential SAFe: The Configuration Floor These Versions Set

The single-train, single-cadence Agile Release Train mechanic traces directly to SAFe 1.0’s 2011 release, where it shipped simply as the framework’s coordination unit: no configuration name attached, because no other configuration existed yet to distinguish it from. SAFe 4.0’s 2016 four-configuration model is where later guidance retroactively labeled that same mechanic Essential SAFe, years after organizations had already been running it under the ART name alone.

That durability matters because configuration proliferation happened almost entirely above this floor, not below it. Large Solution SAFe, Portfolio SAFe, and Full SAFe all stack on top of Essential SAFe; none of them substitute for it. An organization running only Essential SAFe today, on SAFe 6.0 guidance, is running the same structural floor Leffingwell defined in the 2011-2014 window: a single Agile Release Train coordinating multiple teams around a shared Program Increment, governed by the same ten principles. Everything documented in the sections that follow is what got built on top of that floor, not what replaced it.

SAFe 4.0 to 4.6 (2016-2018): Adding Large Solution and Portfolio Configurations Around the Same Principles

SAFe 4.0, released in 2016, introduced the four-configuration model, Essential SAFe, Large Solution SAFe, Portfolio SAFe, and Full SAFe, letting organizations scope their SAFe adoption to their actual complexity instead of installing one fixed shape. Four configuration tiers gave organizations a dial to turn. The adoption research on this exact window shows most organizations turned it to maximum by default, whether their complexity justified it or not.

That gap between what the dial permits and what organizations actually chose is the real story of this era.

The Four-Configuration Model SAFe 4.0 Introduced

SAFe 4.0’s four-configuration split let an organization choose Essential SAFe for a single train, Large Solution SAFe for multi-train coordination on one big solution, Portfolio SAFe for strategy-to-execution funding, or Full SAFe for all three layers stacked together: a scoping decision, not a maturity ladder everyone was meant to climb.

Richard Knaster, SAFe Fellow, contributed the Lean Portfolio Management guidance that this window formalized into the Portfolio SAFe configuration, giving portfolio leaders lean budgets and guardrails instead of annual project funding cycles. A peer-reviewed study of this era, “Issues in the Adoption of the Scaled Agile Framework” (ICSE-SEIP 2022), found this exact four-configuration model is precisely what practitioners reported as most demanding and expensive to operate: not because the configurations were badly designed, but because organizations frequently installed the full stack regardless of whether their actual scale needed it. Choosing the smallest configuration that fits is the practical test of “organize around value,” and the research shows most organizations still fail that test by defaulting upward instead of scoping down.

SAFe 4.5 and 4.6: DevOps and Continuous Delivery Pipeline Refinements

SAFe 4.5 and SAFe 4.6 refined DevOps and Continuous Delivery Pipeline guidance without introducing a fifth configuration tier, functioning as maturity refinements to the 4.0 structure rather than structural expansions of it.

These two point releases matter less for what they added than for what they didn’t: no new configuration, no new principle, no reshuffling of the four-tier model SAFe 4.0 had just introduced. The refinements sharpened how a Continuous Delivery Pipeline should move work from a team’s backlog to production, and deepened DevOps guidance for organizations already running Large Solution or Full SAFe. That restraint is itself informative; Scaled Agile chose to consolidate the configuration model it had just shipped rather than layer a fifth tier on top of a structure the adoption research would later flag as already over-adopted.

Choosing the Smallest Configuration That Fits

Organize around value, applied to configuration choice, means selecting Essential, Large Solution, Portfolio, or Full SAFe based on where the organization’s actual value streams sit: not based on which configuration sounds the most complete on a slide.

The ICSE-SEIP 2022 finding gives this principle teeth: organizations that install Full SAFe by default, without a value-stream reason for the Portfolio or Large Solution layers, are the ones reporting the highest adoption cost relative to benefit. A single Agile Release Train shipping one product line rarely needs Portfolio SAFe’s lean-budget guardrails; a genuine multi-solution enterprise coordinating several Large Solution trains under one strategy usually does. The 2016-2018 configuration window handed organizations that choice explicitly for the first time; what the research shows is how rarely organizations actually exercised it.

SAFe 5.0 (January 2020): Reframing the Ten Principles Around Business Agility

SAFe 5.0, released January 2020, introduced the seven core competencies of business agility, including Team and Technical Agility and Lean-Agile Leadership, as the organizing structure teams and leaders use to operationalize the same ten principles Leffingwell established under the founding versions. Calling it business agility changed the vocabulary leadership used. It did not change what teams were actually asked to decentralize.

Independent research on this exact window complicates the reframe in a way SAFe’s own release notes don’t address.

The Seven Core Competencies of Business Agility

The seven core competencies of business agility gave SAFe 5.0 a portfolio-level vocabulary for organizing the same ten principles, without adding, removing, or rewording a single one of them: the principle text stayed fixed while the competency structure above it changed.

Two principles carried the heaviest re-explanation burden under this new framing: Organize Around Value and Decentralize Decision-Making. Both had existed since the founding versions, but SAFe 5.0’s competency language asked leaders to talk about them differently; as inputs to Team and Technical Agility and Lean-Agile Leadership rather than as standalone Lean-Agile tenets. That’s a real communication shift for an organization rolling out SAFe 5.0 guidance, even though the underlying principle wording an auditor would check against SAFe 1.0 material had not moved at all.

What the Team-Autonomy Case Study Found Underneath the Reframe

“Changes to team autonomy in large-scale software development: a multiple case study of Scaled Agile Framework (SAFe) implementations” (IJISPM, 2022) found autonomy trade-offs persisting under the same Agile Release Train and value-stream structures that the business-agility framing was meant to justify; evidence that reframing principles at the portfolio level doesn’t automatically resolve tension at the team level.

The case study’s teams operated inside the same coordination mechanics the founding versions had already established: shared Program Increments, cross-team dependency sequencing, ART-level ceremonies. Renaming the organizing vocabulary around business agility didn’t remove the coordination cost those mechanics impose on individual team autonomy; teams still had to sacrifice some self-direction to stay synchronized with trains they didn’t fully control. The competency reframe changed what leadership called the trade-off. It didn’t change the trade-off teams were living with.

SAFe 5.1: Consolidation, Not a New Competency Tier

SAFe 5.1 followed as a point release that consolidated existing business-agility guidance rather than introducing an eighth competency or restructuring the seven SAFe 5.0 had just established.

Like the 4.5 and 4.6 point releases before it, 5.1’s restraint is the notable fact: Scaled Agile chose to tighten the competency model it had just shipped instead of expanding it further while the reframe was still being absorbed by practitioners. For an organization auditing which SAFe guidance era it’s running, 5.1 reads as a refinement layer on top of 5.0’s structural change, not a second structural change in its own right.

SAFe 6.0 (March 2023): The Current Version and Its Shift to a Fellows-Authored Framework

SAFe 6.0, published March 2023 and the current major release, turns the economic-view principle into two concrete operating instructions for the first time: deliver early and often, and apply an economic framework; mechanics a team can act on directly, rather than a value statement to interpret. SAFe 6.0 does not add an eleventh principle. It adds a second author: a Fellows network where Leffingwell once wrote alone.

That authorship shift is the structural fact this section is built to name, because it changes how a practitioner should read anything published after 2023.

Deliver Early and Often, Apply an Economic Framework: SAFe 6.0’s Named Operating Practices

SAFe 6.0’s own guidance names two operating practices for realizing the economic-view principle: deliver early and often, and apply an economic framework.

Naming these as explicit operating practices, rather than leaving “take an economic view” as an abstract statement, is itself a small but real change from the founding-version material; SAFe 6.0 spells out the mechanics that earlier guidance implied through WSJF alone. Deliver early and often pushes toward smaller batches and faster feedback loops; applying an economic framework means every trade-off decision, architecture, staffing, sequencing, gets evaluated against Cost of Delay rather than gut feel. Neither practice is new content; both are the founding-version economics, restated with more operational clarity for a 2023 audience that includes AI-era guidance under the Organizational Agility competency.

From a Single Author to a Fellows Network: Who Writes SAFe Guidance Now

Dean Leffingwell continues to oversee SAFe 6.0 guidance through the 2023-2026 window, but most new extension content, AI-era guidance under Organizational Agility, regulated-enterprise guidance, now comes from the SAFe Fellows and SAFe Program Consultants network rather than from a single named author.

That shift matters for how much weight a practitioner should give to any specific piece of post-2023 guidance. Founding-version material carries one author’s coherent reasoning, traceable end to end. SAFe 6.0 extension material carries a distributed network’s output, which brings breadth, more contexts covered, faster response to emerging practice areas like AI-assisted delivery, at the cost of the single-voice consistency the founding versions had. A practitioner reading SAFe 6.0 guidance on a topic Leffingwell personally authored in 2011-2014 and a practitioner reading a 2025 Fellows-authored extension on AI-era Organizational Agility are reading two different governance models, even though both carry the SAFe 6.0 label.

Adapting the Framework to Context: SAFe 6.0’s Response to Over-Adoption

SAFe 6.0 added explicit guidance instructing organizations to adapt the framework to their own context: a direct response to the over-adoption pattern documented earlier in this article. That guidance is concrete rather than aspirational: it directs organizations to select and combine only the elements a value stream’s actual scale requires, and to treat the four-configuration menu as a scoping tool rather than a default checklist meant to be installed in full.

That instruction closes a loop the earlier configuration-proliferation section left open: the four-configuration model gave organizations a scoping dial in 2016, and the research showed most turned it to maximum instead of scoping down. SAFe 6.0’s context-adaptation guidance is the framework’s own acknowledgment of that finding, even if it doesn’t cite the study by name. For an organization deciding what to actually deploy, this is the first version where “adapt to context” appears as explicit governance instruction rather than something a good consultant tells you informally.

How to Identify Which SAFe Version and Configuration Your Organization Is Actually Running

Running a four-step diagnostic against internal guidance and daily practice reveals both the SAFe version an organization’s guidance actually reflects and the configuration it has actually deployed; two separate variables that a version number alone can’t answer. Most audits stop at asking leadership which version they think they’re on, and that question alone answers almost nothing.

Why Are Version and Configuration Two Separate Questions to Diagnose?

The version-versus-configuration distinction already established in this article carries a sharper edge once it becomes an audit question: a version number is a claim nobody can check against anything more concrete than a slide, while a configuration is verifiable directly, against a staffed Release Train Engineer role, a PI Planning cadence that actually runs on schedule, and guidance documents that name a specific deployment scope. Auditing only the version number answers the vocabulary question, whether “core competencies” or “context adaptation” language should be present, but says nothing about scope, and an organization can be running current SAFe 6.0 guidance on top of a configuration far smaller, or larger, than its version number implies. A diagnostic that collapses the two into one score misreads both.

What Makes a Self-Reported Version Audit Unreliable?

Leadership’s stated version number is frequently an outdated artifact rather than a checked fact: a figure someone updated on a slide after a training session, not after a review of what guidance daily practice actually follows. Documentation lags practice in the other direction too: a team can be operating on SAFe 6.0-era cadences and roles while its internal wiki still cites SAFe 5.0 vocabulary, or vice versa, because nobody re-audited the artifacts after the last upgrade. That’s why the diagnostic below checks concrete guidance documents and operating cadences instead of trusting either a title on a slide deck or an unverified verbal answer.

A Four-Step Diagnostic Checklist

The fastest reliable signal comes from checking specific guidance artifacts against the version-specific vocabulary this article has already traced, rather than trusting a self-reported version number that leadership may not have verified in years.

Step one; check for a Lean Portfolio Management structure: a staffed Lean Portfolio budget or guardrail document governing funding decisions, or a Portfolio Kanban actually in active use rather than referenced only in a slide deck. Its absence means the organization predates SAFe 4.0 in practice, regardless of what version number leadership cites: the artifact itself is the diagnostic signal here, not a claim about who wrote the guidance or when. Step two; check whether “core competencies of business agility” appears anywhere in internal guidance documents. That term is SAFe 5.0-specific; its absence signals an organization still running 4.x-era material even if someone recently updated a slide deck to say “SAFe 6.0.” Step three; check whether governance documentation instructs adapting the framework to context, versus prescribing one fixed installation for every team. The former is a SAFe 6.0-specific instruction; the latter is the exact anti-pattern the ICSE-SEIP 2022 research flagged as costly. Step four; separately identify the deployed configuration by checking for concrete operating signals rather than a configuration name on a chart: a Release Train Engineer role that’s actually staffed, a recurring PI Planning cadence that actually happens on schedule, a System Architect role for any Large Solution deployment with a genuine Solution Train, and Inspect and Adapt events that actually occur rather than appearing only in the training deck. Two further signals separate documented SAFe from practiced SAFe day to day: whether an Iteration, the team-level cadence unit inside a Program Increment, is actually running with real boundaries, and whether Kanban is in active use by system or support teams to visualize flow rather than sitting unused on a wiki page.

Reusing the Nordea Action-Research Study’s Method

“Scaled Agile Framework: Software Process-Related Challenges of a Financial Group (Action Research)” (Journal of Software: Evolution and Process, 2022) audited Nordea’s Core Banking Platform program against its nominal SAFe implementation using exactly this kind of structural cross-check, and its method is directly reusable by any organization running its own audit.

The Nordea study didn’t take the program’s claimed SAFe version at face value: it examined organizational constraints, actual role adoption, and corrective actions taken across three qualitative research cycles inside a policy-heavy financial institution, the kind of environment where formal governance and daily practice diverge most visibly. That structured, cycle-based auditing approach parallels a discipline with deeper roots than software: the case-study method the Harvard Business Review pioneered from its 1922 founding under dean Wallace Brett Donham, treating individual organizational cases as a legitimate source of transferable insight rather than anecdote. A century later, that same case-study discipline still anchors the publication’s authority: the Economist called it the publication that “almost single-handedly defines the agenda for management debate.” Nordea’s three-cycle action-research audit and this article’s four-step checklist both borrow the same underlying logic: don’t trust the label, examine the case.

What the Peer-Reviewed Adoption Research Shows About Version-Specific SAFe Outcomes

Six independent, peer-reviewed studies span the SAFe 5.0-to-6.0 publication window, 2020 through 2023, and not one of them organizes its findings by SAFe version number. That absence is itself evidence: the practice-level problems this research documents track configuration and organizational context, not the release label on the box.

Two of those six studies already did the heavy lifting earlier in this article. The other four each measured something distinct enough to deserve its own accounting.

What Does the Six-Study Evidence Base Look Like at a Glance?

Laying the six studies side by side, against venue, year, and citation count, makes the pattern in the research window visible before any single study gets read in depth: no version number is doing any explanatory work in the “what it isolated” column below, only configuration, role, domain, and method.

Study	Venue, Year	Citations	What it isolated
Issues in the Adoption of the Scaled Agile Framework	ICSE-SEIP, 2022	22	Configuration-driven adoption cost
Changes to team autonomy in large-scale software development	IJISPM, 2022	26	Team autonomy trade-offs under ART structures
Product Owner’s Journey to SAFe	Information, 2021	9	A single named role, not a version or configuration
AgiBuild: A Scaled Agile Framework for Building Adaptation Projects	Buildings, 2023	11	SAFe applied outside software entirely
An empirical analysis of success factors in the adaption of the scaled agile framework	arXiv, 2020	5	Earliest study, predates the SAFe 5.0 reframe
Scaled Agile Framework: financial-group action research (Nordea)	J. Softw. Evol. Process., 2022	;	Reusable diagnostic method, covered above

What Do the Citation Counts Reveal About Which Findings Stuck?

The citation counts split unevenly rather than clustering near a single number, and that spread tracks how directly each finding maps onto a problem practitioners recognize. The two studies already covered earlier, team autonomy trade-offs at 26 citations, configuration-driven adoption cost at 22, are also the two most-cited works in the table, which is consistent with them naming a structural problem organizations were already living with rather than a niche or downstream one. The Product Owner role study sits at 9, the outside-software AgiBuild study at 11, and the pre-reframe 2020 baseline at 5; lower counts that fit their narrower scope rather than any weaker finding. Citation count is not a substitute for reading a study, but the spread itself establishes the same point the table’s “what it isolated” column makes: uptake in the field followed the structural and configuration questions, not a version-number narrative.

Six Studies, What Each One Actually Measured

The IJISPM team-autonomy study and the ICSE-SEIP adoption-issues study, both introduced earlier in this article, remain the two most-cited works in this evidence base. What ties them together methodologically is qualitative case design, both drew on interviews and document review across multiple organizations rather than a survey instrument, which is part of why their findings read as structural rather than anecdotal, and neither study frames a single finding around which SAFe version number its case organizations happened to be running.

Product Owner’s Journey to SAFe; Role Changes in Scaled Agile Framework (Information, 2021, 9 citations) is the only study in the corpus that isolates its findings to a single named SAFe role rather than to a version or configuration, tracking how the Product Owner’s responsibilities shift once scaled beyond a single team. AgiBuild: A Scaled Agile Framework for Building Adaptation Projects (Buildings, 2023, 11 citations) is the only study applying SAFe outside software entirely, to building-adaptation and refurbishment projects, and the most recent publication in the evidence base, suggesting SAFe’s coordination mechanics are being tested well past their original domain. An empirical analysis of success factors in the adaption of the scaled agile framework (arXiv, 2020, 5 citations) is the earliest and least-cited study here, predating the SAFe 5.0 business-agility reframing entirely, which makes it a useful pre-reframe baseline for anyone comparing outcomes across the 2020 line. A separate, Agile Alliance-published experience report on agile transformation sits in a different evidentiary category from all six: a practitioner account of what worked inside one organization, not peer-reviewed research; useful context, but not evidence with the same standing as the six studies above it.

Why None of Them Organizes Findings by Version Number

None of the six most-cited independent SAFe adoption studies structures its results around SAFe 1.0, 4.0, 5.0, or 6.0 as an explanatory variable; every one of them organizes findings around configuration, role, or organizational context instead.

That pattern is the strongest evidence available that SAFe Framework Version History functions as a governance narrative for practitioners and vendors, not as a research variable that predicts outcomes. A team’s autonomy trade-off, an organization’s adoption cost, a Product Owner’s role strain; none of these correlate with which version number appears on the internal wiki page. They correlate with which configuration got deployed, how closely daily practice matches documented guidance, and how much the organization adapted the framework to its own context rather than installing it whole. The four-step diagnostic earlier in this article exists for exactly this reason. The version number a practitioner is handed answers a much smaller question than it appears to.

Summary

Two axes explain everything documented above: a version axis that moved six times since 2011, and a principle axis that has not moved at all; auditing an organization’s SAFe deployment means tracking both separately, not collapsing them into one number.

The Principle Layer Never Moved

Every structural change this article traces, the Agile Release Train in the founding versions, the four-configuration split in SAFe 4.0, the business-agility competencies in SAFe 5.0, the Fellows-authored extensions in SAFe 6.0, happened at the practice layer sitting above Dean Leffingwell’s original ten principles, never inside the principle text itself.

That distinction has a practical consequence beyond historical accuracy: an organization that finds its SAFe deployment underperforming rarely needs to relitigate whether the ten principles are sound. The economic-view principle traces cleanly back through six versions to Reinertsen’s pre-2011 flow research, and that pattern isn’t an exception; every one of the ten has been reframed under new competency and configuration vocabulary release after release without the principle text itself ever being rewritten. What actually breaks, when SAFe deployments break, sits in the layer that moved, the configuration chosen, the roles staffed, the cadences actually run, not in the reasoning underneath it. Diagnosing a struggling deployment against version history alone misses where the failure almost always lives.

Diagnose by Structure, Not by Version Number

The four-step diagnostic and the six-study research review both converge on the same practical instruction: check Lean Portfolio Management structures, business-agility vocabulary, context-adaptation guidance, and actual role and cadence signals: not the version number a leadership deck reports.

That convergence is not a coincidence, and it points to one action rather than one more citation: run the four-step diagnostic against your own guidance artifacts and cadences before trusting any version number a leadership deck reports. An organization auditing its own SAFe maturity should follow the same discipline: treat the version number as a rough timestamp for which guidance vocabulary should be present, and treat the configuration, the staffed roles, and the running cadences as the actual evidence. SAFe Framework Version History answers when guidance was published. It was never designed to answer whether an organization’s deployment is working.

agility at scale