Agile Manifesto and SAFe’s Relationship to Foundational Agile

SAFe's Product Owner page quotes a Manifesto principle, then adds a full-time role the document never specified — SAFe's citation-vs-addition pattern.

Scaled Agile’s own Product Owner page quotes the Agile Manifesto’s principle on business people and developers working together daily, then defines a permanent, full-time role the document’s authors never specified: the clearest evidence that even SAFe’s official pages can’t decide whether they’re honoring the Agile Manifesto and SAFe’s relationship to foundational Agile or quietly rewriting it.

---

The Agile Manifesto’s Origins: Who Wrote It at Snowbird and Why

Seventeen software practitioners drafted the Agile Manifesto during a three-day meeting at Snowbird, Utah, in February 2001, formalizing values and principles that had already been circulating informally among lightweight-methods advocates for nearly a year. The meeting reads in most retellings as a spontaneous ski-lodge gathering, but the sequence that produced it started months earlier, in a rural Oregon retreat most summaries skip entirely.

Kent Beck’s Spring 2000 Oregon Retreat and the Path to Snowbird

In the spring of 2000, Kent Beck invited a group of active Extreme Programming practitioners to his home in rural Oregon to work through disagreements inside the XP community. Alongside established XPers, Beck also invited people who were interested in but separate from XP, Alistair Cockburn, Jim Highsmith, and Dave Thomas among them, widening the conversation past a single methodology. The group agreed that XP worked best as its own specific process, what Martin Fowler later called “a stake in the ground,” but they also found substantial common ground between XP and the cluster of approaches then labeled Lightweight Methods; Scrum, DSDM, and Feature-Driven Development among them Feature-Driven Development (Martin Fowler).

That shared ground is what made a bigger meeting worth having. Robert Martin, present at the Oregon retreat, decided to convene a wider gathering covering the full range of lightweight approaches rather than XP alone. He reached out broadly, contacting whoever the Oregon group believed was active and engaged in the field, and after considerable back-and-forth the group decided on a location and date: Snowbird, Utah, February 11-13, 2001 Feature-Driven Development (Martin Fowler). The retreat didn’t produce a manifesto: it produced the guest list and the shared premise that made one possible.

The Snowbird Meeting: February 11-13, 2001

Robert Martin organized the Snowbird gathering after the Oregon retreat surfaced enough common ground between Extreme Programming and other lightweight methods to justify a broader conversation, drawing seventeen participants to a Snowbird Utah ski lodge for three days in February 2001. Fowler, one of the seventeen, later described himself as one of the “self-elected visionaries” present, and his own account remains the primary record of how the group’s internal debates resolved into a single document Feature-Driven Development (Martin Fowler).

The period context makes the moment easier to place: Scaled Agile’s own twentieth-anniversary retrospective notes that Enron was still seventh on the Fortune 500, Python, PHP, and Lisp were the working languages of the day, Apple hadn’t yet shipped the first iPod, and Wikipedia was still weeks from launching (Scaled Agile). Software delivery, by contrast, ran on rigid, top-down, documentation-heavy processes that the seventeen founders had all separately grown frustrated with; frustration that gave the meeting its working urgency despite its casual setting.

Who Robert Martin Invited

Robert Martin’s invitation list extended well past the Extreme Programming contingent that had met in Oregon, deliberately pulling in figures who represented other lightweight approaches: Alistair Cockburn (Crystal), Jim Highsmith, and Dave Thomas, alongside the established XPers who had already debated common ground at the earlier retreat. The goal wasn’t consensus among people who already agreed: it was assembling representatives of the different methodologies competing for the same territory, so that whatever emerged would speak for the field rather than for one process.

That breadth mattered because it shaped what could persist as shared language. A meeting confined to XP practitioners would have produced XP’s vocabulary; a meeting spanning Scrum, DSDM, Feature-Driven Development, and Crystal produced values abstract enough that none of the specific methodologies had to concede its own practices to sign on Feature-Driven Development (Mike Cohn). The four values that resulted read as principles precisely because the room had no single process to defend.

Choosing the Word ‘Agile’

Before Snowbird, the group of approaches now called “agile” had no shared name; practitioners referred to XP, Scrum, DSDM, and their relatives collectively as Lightweight Methods, a label that described what the approaches lacked rather than what they offered. At the Snowbird meeting itself, the participants decided to replace that name with “agile,” a term chosen specifically to describe the new breed of methods without echoing the earlier label’s negative framing Feature-Driven Development (Martin Fowler).

The renaming carried weight beyond marketing. “Lightweight” invited the obvious rebuttal, that serious software development needed heavyweight process, while “agile” asserted a positive claim about responsiveness instead of a negative one about the absence of ceremony. Every later structural choice, including the values-and-principles format the group decided on, inherited that same instinct: state what the approach does, not what it skips.

Ward Cunningham’s Email and the Agile Alliance

Mike Cohn learned the Manifesto existed only after Ward Cunningham emailed him a link to a new site, agilemanifesto.org, in the days after the Snowbird meeting closed. Cohn wasn’t at Snowbird, and by his own account he’d spent the prior years doubting his team’s choice to use Scrum; most of the industry buzz at the time was around the Unified Process, and using “this little toy of a process called Scrum” felt like a risk nobody else was taking Feature-Driven Development (Mike Cohn).

Cunningham’s email read simply, “Look how I spent the last few days,” with a link and a photo of people standing around a whiteboard. Cohn described the site hitting him “like a lightning bolt.” His team wasn’t alone; at least seventeen other people had reached the same conclusions independently. Day by day, more names appeared on the site, each adding a brief statement of solidarity to the growing list of signatories Feature-Driven Development (Mike Cohn).

The seventeen founders didn’t stop at publishing a document; they founded the Agile Alliance as the meeting’s ongoing organization, giving the loose coalition a structure that could outlast the initial burst of attention. Fowler continued that work through Thoughtworks, carrying the ideas into consulting practice rather than leaving them as a one-time artifact Feature-Driven Development (Martin Fowler). What the seventeen produced, formally, was compact: four values and twelve principles, published under the name chosen at Snowbird to replace “Lightweight Methods” Lightweight Methods (Agile Alliance). Every framework that has since claimed lineage from that document, SAFe included, inherits exactly that: four values, twelve principles, and nothing more specific than that.

Why Did They Call It a ‘Manifesto’?

The document the seventeen produced carries a formal title most casual references drop entirely: “Manifesto for Agile Software Development,” opening with a single line of intent, “We are uncovering better ways of developing software by doing it and helping others do it”, before the four values follow Lightweight Methods (Agile Alliance). A manifesto declares a position rather than prescribing a procedure, which matched what the room had actually agreed to: shared values across competing methodologies, not a single standardized process every signatory would have to adopt.

That format choice reinforced the same instinct that drove the rename from “Lightweight Methods” to “agile.” A standard or a certification body would have required the room to pick a winner among XP, Scrum, DSDM, and the rest; a manifesto let all of them keep their own practices while committing to values none of them owned individually. The four values published under that title are what every later framework, SAFe included, inherited: not a process to follow, but a position to measure against.

---

What SAFe Inherited From the Agile Manifesto, and Where Its Principles Depart

Scaled Agile’s own Product Owner page quotes a Manifesto principle as its epigraph and then defines a permanent, full-time role for every team that the Manifesto’s authors never specified, marking the exact line between what SAFe inherited and what Dean Leffingwell added to coordinate work at scale. That epigraph is the strongest evidence of lineage anywhere in the framework; and the role built beneath it is the strongest evidence of departure.

The Product Owner Page’s Own Epigraph: A Manifesto Principle Made Structural

Scaled Agile’s official Product Owner page opens with the Agile Manifesto principle “Business people and developers must work together daily throughout the project” as its epigraph, before defining the role that principle became inside SAFe Agile Manifesto (Scaled Agile Framework). The Product Owner is defined as the Agile Team member primarily responsible for maximizing delivered value by keeping the team backlog aligned with customer and stakeholder needs: the “voice of the customer” inside the team.

That’s a direct citation, not an inference: SAFe’s own documentation treats the daily-collaboration principle as the justification for the role, not as background color. But a principle describing daily conversation between business people and developers is not the same claim as a named, permanent position; and SAFe’s page makes that gap explicit in its own next sentence, which turns the citation into an addition.

That sequencing, quote the principle, then build a structure around it, puts SAFe in an unusual position relative to most enterprise delivery frameworks. Rather than claiming independent authority for the Product Owner role, Scaled Agile grounds its accountability directly in the founding document of the movement it scales, treating the epigraph as evidence rather than decoration. A reader checking any other SAFe role against the Manifesto can use the same test this page demonstrates: look for the specific principle a role traces back to, then check whether what SAFe built goes beyond what that principle actually said.

Where SAFe Adds Structure the Manifesto Didn’t Specify

The Agile Manifesto’s twelve principles describe an ad hoc collaboration model without naming a single role, so every position SAFe formalizes represents a structural choice the founding document left to team discretion. Scaled Agile’s Product Owner page states the departure directly: for most organizations moving to Agile, the Product Owner is a new, full-time role for each team: a permanent structure the daily-collaboration principle doesn’t itself prescribe Agile Manifesto (Scaled Agile Framework). Both roles examined here are examples of the structured roles SAFe Lean-Agile Principles formalize that the Manifesto’s twelve principles leave to team discretion.

The Full-Time Product Owner Role

SAFe’s Product Owner definition converts an ad hoc expectation, business people and developers talking daily, into a dedicated, permanent seat on every Agile Team, with defined responsibilities for backlog alignment, stakeholder communication, and value maximization. The Manifesto’s principle describes an interaction pattern; SAFe’s role describes a person accountable for making that pattern happen consistently across a team’s entire lifespan.

That distinction matters most at the point where daily collaboration would otherwise break down. Without a dedicated Product Owner, backlog alignment across a large program depends on whichever business stakeholder happens to be available that week, and priorities shift as different voices fill the gap inconsistently. Naming one person accountable for maximizing delivered value gives large organizations a single point of alignment the original principle never guaranteed on its own Agile Manifesto (Scaled Agile Framework).

The Release Train Engineer

The Release Train Engineer has no equivalent anywhere in the Manifesto’s twelve principles, because those principles were written with a single team’s coordination in mind, not a train of teams delivering one solution together. The role exists specifically to synchronize planning, dependencies, and delivery cadence across every team on an Agile Release Train; work that a document addressed to individual teams was never built to specify Agile Release Train (Agile Alliance).

That absence is instructive rather than accidental. The Manifesto’s principle on sustainable pace and its principle on face-to-face conversation both assume a group small enough to coordinate informally; scale that group past what informal coordination can carry, and something has to take over the synchronizing work. The Release Train Engineer is SAFe’s answer to a coordination problem the original twelve principles simply never had to solve.

Dean Leffingwell’s Coordination-at-Scale Design

Dean Leffingwell built SAFe to answer a coordination question the Agile Manifesto’s twelve principles never addressed: how multiple teams building one solution work together, not just how one team works. The Manifesto’s guidance, face-to-face conversation, sustainable pace, working software as the primary measure of progress, was written for a single co-located team and says nothing about what happens when a dozen teams share dependencies on one release.

Leffingwell’s design decisions read as answers to that specific gap: the Release Train Engineer, the Product Owner’s formalized backlog role, and program-level planning cadences all exist to keep multiple teams synchronized without requiring every team to negotiate coordination from scratch each iteration (Agile Alliance’s own examination of the Manifesto’s values and principles notes the same scope limitation directly). What SAFe added wasn’t a rejection of the twelve principles: it was a layer addressing a scale the principles were never asked to govern.

That distinction is worth holding onto whenever an evaluation of SAFe’s fidelity to its roots comes up. A team-level principle written for a group small enough to fit in one room doesn’t automatically scale to a dozen teams sharing a release just because the words could technically still apply; something has to fill the coordination gap once informal daily conversation stops reaching everyone who needs it. Leffingwell’s contribution was recognizing that gap early and designing roles and cadences to fill it deliberately, rather than leaving large organizations to improvise their own answer team by team.

SAFe’s Own Four Core Values Alongside the Manifesto’s Original Four

SAFe layers a separate set of four SAFe Core Values, Alignment, Built-In Quality, Transparency, and Program Execution, on top of the Manifesto’s original four values rather than replacing them. SAFe’s own reference material describes the Manifesto itself as “the seminal Agile document describing the four values and twelve principles of Agile software development” Core Values (Scaled Agile Framework), treating that structure as the foundation its own four Core Values sit beside rather than substitute for.

The two sets of four aren’t parallel translations of each other, some SAFe values answer scale questions the Manifesto never posed, while others extend a Manifesto principle to a multi-team setting:

SAFe Core Value	What It Governs	Manifesto-Era Equivalent
Alignment	Keeps distributed teams and Agile Release Trains pointed at the same strategic intent	No direct equivalent, added for multi-team coordination
Built-In Quality	Embeds testing, integration, and design discipline into daily work instead of a late-stage gate	Extends the principle on continuous attention to technical excellence
Transparency	Makes work visible across Portfolio, Program, and Team levels	Extends the preference for working software as the primary measure of progress
Program Execution	Prioritizes predictable, working software delivered through the Agile Release Train	Extends “deliver working software frequently” to a multi-team cadence

Reading the table left to right shows the same pattern that runs through the Product Owner and Release Train Engineer: two of SAFe’s four values extend a Manifesto principle to a larger unit of work, and two answer coordination questions the Manifesto’s single-team frame never raised at all.

---

When the Manifesto’s Own Authors Became Its Critics

Martin Fowler, one of the Agile Manifesto’s seventeen authors, told his 2018 Agile Australia keynote audience that most of what carries the agile label today is “faux-agile”; work that disregards the values and principles he helped write seventeen years earlier. A signatory calling his own movement’s output fake carries more weight than an outside critic ever could, and Fowler didn’t stop at the accusation; he named the mechanism.

Fowler’s 2018 Verdict: The Agile Industrial Complex and ‘Faux-Agile’

Fowler named the mechanism behind faux-agile directly in that keynote: an “Agile Industrial Complex” that imposes process on teams from the outside, the exact inversion of the Manifesto’s first value of individuals and interactions over processes and tools. He drew the contrast between agile’s mainstream success that had become visible on the surface, the methodology is now everywhere, and what he called a troubling reality underneath it, where adoption at scale had produced imposed process rather than the negotiated, team-owned practice the Manifesto described (Martin Fowler).

The Agile Industrial Complex, in Fowler’s perspective, names the pattern of consultancies, tooling ecosystems, and rigid rollout playbooks that convert agile from a set of team-level choices into a top-down mandate: a pattern larger than any single vendor or certification body. That inversion is precisely what the Manifesto’s founders spent 2001 arguing against: process handed down instead of practices a team adopts because they work.

A signatory naming this pattern in public, seventeen years after co-writing the founding values, carries a specific kind of authority an outside consultant’s critique never could. Fowler’s target is narrower than a claim that agile as a category failed: he argues that a large share of what gets sold and rolled out under the label inverted the very value it claims to honor, and that the mainstream success of the word “agile” masked exactly that inversion for years.

The Three Fights Fowler Named

Fowler used the same keynote to name three specific fights the agile community needed to have in 2018: fighting the Agile Industrial Complex itself, raising the priority of technical excellence, and organizing teams around products instead of projects. Each fight targets a different failure mode he’d observed accumulate over seventeen years of mainstream adoption.

The technical excellence fight responds to teams that adopted agile ceremonies, standups, sprints, retrospectives, while letting code quality and design discipline slide, treating agility as a scheduling change rather than a craft discipline. The product-versus-project fight targets organizations that still fund and staff work as temporary projects with fixed end dates, even while running Scrum or Kanban inside them, which undercuts the sustainable-pace and continuous-improvement principles that assume a standing team rather than a disbanding one (Martin Fowler). None of the three fights argues that agile itself failed: each argues that specific implementations quietly abandoned the values while keeping the vocabulary.

The three fights connect to each other rather than standing as a loose list. Process imposed from outside a team (the Agile Industrial Complex) tends to arrive precisely where technical excellence has already slipped, because a team producing brittle code under pressure becomes an easier target for a consultancy selling standardized process as the fix. Project-based funding compounds both problems: a team staffed for one project’s duration has less incentive to invest in the technical excellence that pays off over years, and less standing to resist imposed process when its funding depends on someone else’s approval each cycle.

How Executives Misread the Manifesto, Per Rigby and Sutherland

Darrell Rigby of Bain & Company and Jeff Sutherland of Scrum Inc name two specific ways executives misread the Agile Manifesto: as anarchy, or as command dressed in agile language. Writing with Hirotaka Takeuchi of Harvard Business School in Harvard Business Review, the two describe executives who assume agile means “everybody doing what he or she wants to do,” alongside a second group of executives who read it as license to demand more speed without changing how decisions get made; what Sutherland characterized in one HBR interview as “doing what I say, only faster” (Harvard Business Review).

Both misreadings share a structural flaw: neither treats the Manifesto’s values as a description of how decision rights actually move inside a team. Anarchy assumes no structure at all; command-dressed-as-agile assumes the old structure persists unchanged under new vocabulary. Rigby and Sutherland’s HBR account argues the real practice sits between those two extremes; bounded autonomy, not the absence of authority and not its disguise.

Rigby’s own background gives the misreading claim extra weight: as a partner leading Bain & Company’s Global Innovation and Retail practices, he watches the same document get introduced into large organizations repeatedly across industries far outside software, and the two failure patterns he and Sutherland describe recur regardless of sector. An executive who defaults to either extreme rarely does so out of bad faith; command-dressed-as-agile in particular often starts as a genuine attempt at speed that quietly reverts to the reporting lines and approval gates the team already knew.

What the Manifesto Assumes but Never States, Per Timothy Clark

Timothy Clark argues in Harvard Business Review that the Agile Manifesto’s four values assume psychological safety, people secure enough to say what they actually think, an assumption absent from all twelve principles. Clark, writing twenty-one years after the seventeen engineers published the document, frames psychological safety as the precondition the entire framework quietly depends on: face-to-face conversation only lets useful information emerge if the people in the room feel safe raising a problem, and responding to change only works if team members feel safe flagging that change is needed (Harvard Business Review).

That omission is consequential precisely because it’s invisible in the text. A team can implement every ceremony the Manifesto and its twelve principles describe, daily standups, iteration reviews, retrospectives, and still fail if the underlying culture punishes people for surfacing bad news. The Manifesto tells teams what to do when the room is safe; it never tells them how to make the room safe in the first place, leaving that precondition as unfinished business for every organization that adopts the document at face value.

Clark’s timing matters as much as his argument. Writing in 2022, two decades into the document’s life, he’s diagnosing a gap that persists through every prior wave of agile scholarship and tooling, which suggests psychological safety functions as a condition teams have to actively maintain alongside whatever ceremonies they run, rather than a prerequisite a maturing team eventually checks off once and moves past.

---

Does the Manifesto Hold at AI-Native Speed? The Obsolescence Debate

Steve Jones, an executive vice president at Capgemini, argued in a widely discussed 2026 post that agentic Software Development Lifecycle systems have broken the Agile Manifesto’s four values and twelve principles because the tools teams use now matter as much as how they collaborate. Mike Cohn answers that argument point for point, naming exactly what happens when teams take Jones’s advice and let tooling replace conversation. The debate isn’t new in spirit, the Lean Enterprise Institute’s 2024 Lean Summit featured Fabrice Bernhard’s own “Lean Tech Manifesto” keynote, arguing that technology organizations need a founding document of their own for reasons that echo 2001 Lean Tech Manifesto (Lean Enterprise Institute), but the speed of agentic tooling has made the question urgent again.

Steve Jones’ Case: Why Agentic SDLCs Are ‘Too Fast for Agile’

Jones argues that Agentic Software Development Lifecycle systems break with Agile principles because agentic SDLCs generate working code faster than two-week sprint cycles or manual documentation can track. His argument, carried to a software-delivery audience through InfoQ’s own coverage of the debate, centers on a direct conflict: the Manifesto’s preference for individuals and interactions over processes and tools assumed tools were roughly interchangeable, and Jones argues that assumption no longer holds (InfoQ).

Jones published the argument first as a Medium post and a companion LinkedIn post before InfoQ picked it up, and the combination is part of why the debate spread quickly through software-delivery circles rather than staying confined to one platform’s comment section. His framing treats the Manifesto’s twelve principles as written for a specific pace of change, one where a tool decision made in January still held by June, and argues that agentic development collapses that timeframe into days, leaving the principles addressed to a delivery rhythm that no longer describes how the work actually happens.

Jones’s title as an executive vice president at Capgemini, a consultancy that sells delivery capability to large enterprises, gives the argument a different kind of standing than a lone practitioner’s blog post would carry; Capgemini’s clients are exactly the organizations deciding right now whether to fund agentic tooling adoption at scale, which is part of why InfoQ treated the post as debate-worthy news rather than opinion commentary.

Two Named Fault Lines Jones Identifies

Jones names two separate fault lines where agentic development breaks the Manifesto’s assumptions: a tooling problem and a documentation-debt problem hiding behind code that only appears to work. On the documentation side, he argues AI agents excel at producing software that looks functional while accumulating technical debt at a pace manual review can’t keep up with: the code works for the specific instructions given, and nothing more (InfoQ).

Both fault lines share a root cause in Jones’s account: agentic systems optimize for passing the immediate check, compiling, running, satisfying the stated instruction, rather than for the broader intent a human reviewer would have inferred from context. That gap between passing-the-check and matching-the-intent is where he locates the real risk, since it’s invisible until a team hits the edge case the original instruction never anticipated.

The Tooling Problem: Replit Versus Claude Code

Jones’s tooling argument is specific rather than general: using Replit produces materially different development outcomes than using Claude Code, and a team mixing multiple agentic SDLCs has to actively plan for that variance rather than treating tool choice as incidental. That claim directly conflicts with the Manifesto’s stated preference for individuals and interactions over processes and tools, which assumed tool choice was a background decision, not a first-order one (InfoQ).

The practical consequence is that tool selection now belongs in planning conversations that used to skip it entirely. A team choosing between agentic coding tools is making an architectural decision with downstream effects on code quality and delivery speed; closer to choosing a framework than to choosing an editor, and worth the same deliberate evaluation.

The Two-Week Sprint Cycle Looks Antiquated

Jones describes agentic SDLCs creating working applications in hours and migrating entire applications in a single flight, a speed differential that makes the traditional two-week sprint cycle look like a relic of an era when code took days to write. If a feature that once justified a two-week iteration boundary can be generated and tested in an afternoon, the cadence itself stops matching the actual pace of the work moving through it (InfoQ).

That mismatch doesn’t resolve itself automatically. Teams that keep the two-week boundary out of habit end up batching finished, working code and sitting on it until the next planned review: the opposite of the Manifesto’s principle on delivering working software frequently, ironically preserved by clinging to the cadence that principle was meant to accelerate.

Mike Cohn’s Counter: AI Amplifies Misalignment

Mike Cohn counters Jones’s obsolescence argument with an observed failure pattern: teams excited by AI’s efficiency quietly collaborate less, reasoning that if AI generates stories, code, and tests there’s less left to discuss. Cohn states his conclusion directly, AI amplifies everything, including misalignment, which makes the individuals-and-interactions value more load-bearing under agentic tooling, not less (Mike Cohn). Cohn frames this as a drift he has watched happen gradually across multiple teams, not a single dramatic failure: Product Owners generate and split backlog items with AI assistance, developers accomplish more without checking in, and the daily conversation the Manifesto treats as central quietly shrinks to a status update.

The mechanism Cohn describes runs opposite to Jones’s speed argument without contradicting the underlying facts. Both agree agentic tooling moves faster than manual development; they disagree about what that speed does to the team using it. Cohn’s account, and the Lean Enterprise Institute’s own coverage of AI adoption elsewhere in the industry, interpreting the pattern as AI exposing the organizational immune system nobody wanted to talk about (Lean Enterprise Institute), both point to the same underlying claim: speed doesn’t remove coordination problems, it just removes the time teams previously had to notice them before they compound. The open question is whether a team moving that fast can still tell when it has stopped talking to itself, regardless of how the Manifesto’s cadence holds up against agentic tooling speed.

---

Measuring Agreement With the Manifesto: A Validated Values-Versus-Practices Scale

A 2026 University of Namur study by Nicolas Matton and colleagues develops and validates two distinct psychometric instruments for measuring “agile agreement,” closing a methodological gap where prior research never separated agreement with the Manifesto’s abstract values from agreement with its twelve principles’ concrete practices. The instruments matter because they let a team’s stated belief in agile values get checked against what it actually does; and the two turn out not to move together.

Nicolas Matton and the University of Namur Research Team

Nicolas Matton led a University of Namur research team, with Anthony Simonofski, Marie-Ange Remiche, and Benoit Vanderose, that published the 2026 paper developing the Manifesto Agreement Scale and the Principle Agreement Scale. The team, based across the university’s Faculty of Computer Science and School of Management, framed the work as addressing a specific measurement problem rather than offering another opinion piece on whether teams “really” practice agile Intraclass Correlation Coefficient (University of Namur research team).

Publishing two coordinated instruments rather than one blended survey was itself a methodological choice, built to keep two different questions, do you believe in this value, and do you actually do this practice, from collapsing into a single ambiguous score. That separation is what makes the resulting findings usable for diagnosis rather than just sentiment tracking.

The paper’s academic perspective sets it apart from most existing writing on Manifesto adherence, which tends to argue from example or anecdote rather than from a tested measurement instrument. Matton’s team went through the full sequence a validated scale requires, item creation, item selection, survey administration, and statistical testing for internal consistency, before treating either scale as ready for comparison against the other, work that gives the resulting numbers a different evidentiary weight than a consultant’s informal maturity assessment.

The Methodological Gap: Values Agreement Versus Practice Agreement

Prior research into agile agreement failed to distinguish agreement with the Manifesto’s abstract, high-level values from agreement with the concrete, day-to-day practices the twelve principles derive, a gap Matton’s team set out to close. Earlier instruments typically asked practitioners to rate their overall alignment with “agile,” collapsing a team’s endorsement of an abstract value like customer collaboration together with their actual behavior on that value’s derived practices, such as daily conversations with business stakeholders.

That collapse matters because organizations routinely score high on stated belief while scoring low on practice, or the reverse: a team can believe in responding to change while running a change-control process that makes responding to change organizationally difficult. A single blended score hides exactly the gap an organization most needs to see.

The gap Matton’s team identifies also explains why so many “agile maturity” assessments produce inconsistent results across the same organization. A survey that asks respondents to rate general alignment with agile invites each person to answer from whichever layer feels most salient to them, one respondent scoring from conviction, another from observed daily practice, which means the same organization can produce contradictory maturity scores depending on which layer happened to be top of mind for whoever answered.

Two Named Instruments

The team built two separate scales rather than one blended instrument: the novel Manifesto Agreement Scale and a systematic adaptation of a prior instrument called the Principle Agreement Scale. Both went through item creation, selection, and survey validation before being tested against each other for convergence and divergence. Building two scales instead of a single hybrid measure was a deliberate methodological decision, since collapsing values-level and practice-level items into one instrument would have reintroduced the exact ambiguity the paper set out to eliminate.

The Manifesto Agreement Scale (MAS)

The Manifesto Agreement Scale is the paper’s novel contribution, purpose-built to measure agreement with the four abstract values as stated, individuals and interactions, working software, customer collaboration, and responding to change, independent of any specific practice a respondent might associate with them. It asks about belief in the value itself, not about the presence or absence of a particular ceremony.

That separation gives organizations an early-warning instrument: a team or leadership group can score high on MAS while their actual delivery practice, measured separately, tells a different story. Isolating the values layer this way lets a diagnosis start with “do we believe this” before moving to “do we do this,” rather than assuming the two always travel together.

The Principle Agreement Scale (PAS)

The Principle Agreement Scale is a systematic adaptation and refinement of a prior instrument, rebuilt to measure agreement with the twelve concrete, day-to-day practices the principles derive from the four values: the practical layer sitting underneath the abstract one MAS measures. Where MAS asks about belief, PAS asks about behavior at the level of specific practices like frequent delivery and daily business-developer conversation.

The practical use case is diagnostic rather than academic: a team scoring low on PAS despite scoring high on MAS has identified precisely where its aspiration and its daily behavior diverge, which is a more actionable finding than a single combined score that only says something is off without saying what.

What the Convergence Analysis Found

The convergence-and-divergence analysis found the two scales moderately correlated but not interchangeable, each capturing a distinct dimension of agile agreement rather than one shared underlying construct. Matton’s team ran the comparison using Proportional Odds Logistic Regression, a Bland-Altman plot, and an Intraclass Correlation Coefficient, alongside separate internal consistency and construct validity testing for each scale individually Intraclass Correlation Coefficient (University of Namur research team).

The results were validated within a specific demographic of Belgian IT professionals, giving the pair of instruments an initial, bounded evidence base rather than a universal claim. A team that scores high on MAS but low on PAS has located belief without practice; the reverse pattern flags practice running ahead of genuine conviction: a distinction that informal “how agile are we” surveys have never been built to make.

The moderate-correlation finding is itself the paper’s most useful result for practitioners, more than either scale’s score in isolation. If the two instruments had turned out fully interchangeable, one would have been redundant; if they’d shown no relationship at all, the case for treating them as two views of the same underlying construct would have collapsed. Landing in between showed that values agreement and practice agreement are related but separable, which is exactly the premise an organization needs before it can use the pair diagnostically rather than as a single combined vanity metric.

---

Summary

The Agile Manifesto and SAFe’s relationship to foundational Agile comes down to a citation-versus-addition test: does a given structural choice quote a principle the Manifesto already stated, or answer a coordination question the twelve principles never addressed?

Where SAFe’s Structure Answers a Real Coordination Gap

SAFe’s Product Owner role, Release Train Engineer, and layered Core Values each trace back to a specific gap the Manifesto’s single-team frame left open: keeping a dozen teams aligned on one release. Scaled Agile’s own documentation makes the lineage visible: the Product Owner page opens with a Manifesto principle as its epigraph before defining a role the principle never specified, and that pattern of cite-then-extend runs through Dean Leffingwell’s broader design, not just one role.

Recognizing that pattern gives a practitioner a usable test for any SAFe practice under evaluation. Ask whether the practice extends a principle to a scale the principle didn’t anticipate, or whether it substitutes for a principle the team could have satisfied on its own. Program-level planning cadence and dedicated coordination roles tend to answer the first kind of question; process layered on top of a team that was already communicating daily tends to answer the second, and Fowler’s own faux-agile verdict is the sharper warning here; citing the Manifesto’s language protects nothing if the daily practice underneath contradicts the value that language claims to honor. The Agile Industrial Complex Fowler named grows exactly where organizations stop at the citation and skip the harder work of checking whether the practice underneath still serves individuals and interactions over process for its own sake.

Agentic Speed Raises the Weight on Individuals and Interactions

Jones’s obsolescence argument and Cohn’s collaboration-collapse counter aren’t really disagreeing about facts; both accept that agentic tooling moves faster than manual development ever did. They disagree about what that speed does to a team, and Matton’s Manifesto Agreement Scale and Principle Agreement Scale pair is built to answer exactly that kind of question empirically rather than by argument alone: whether a team’s stated belief in individuals and interactions still matches what it actually does once tooling accelerates delivery.

The practical implication is a sequencing rule, not a verdict on whether agentic development is compatible with the Manifesto. As delivery speed increases, the values-versus-practice check needs to run more often, not less, because misalignment compounds faster when the team generating code in minutes has no built-in moment to notice communication quietly dropping off. A team that waited a full quarter to check MAS against PAS in 2015 can’t wait that long once its sprint cadence has effectively evaporated: the gap between professed value and daily behavior that Timothy Clark located inside psychological safety, and that Matton’s team built two separate scales to measure, only grows wider the faster the underlying work moves.

None of that resolves the Jones-versus-Cohn debate outright, and it isn’t meant to. It gives a team a way to stop arguing about whether agentic tooling is generally compatible with the Manifesto and start checking its own specific gap between stated belief and daily behavior, on a cadence that matches how fast its delivery pace has actually changed.