Agile Manifesto

Definition: The Agile Manifesto is a 68-word statement of software development values published in February 2001 by seventeen practitioners meeting at Snowbird, Utah, accompanied by twelve supporting principles. It expresses four preferences of the form “we value X over Y” — not four rules, and not a process. It deliberately prescribes no roles, no ceremonies, no artifacts, and no practices; it is a philosophy that concrete frameworks such as Scrum, Kanban, and Extreme Programming (XP) implement in mutually incompatible ways. Almost every recurring misuse of the word “Agile” traces back to ignoring a single clause inside the document itself.

How It Works

The Snowbird Gathering, February 2001

Seventeen people met at the Snowbird ski resort in Utah on 11–13 February 2001. They were not a standards body, a consortium, or a vendor alliance. They were authors and practitioners of what were then called “lightweight” methodologies — a label most of them disliked — who had independently reached similar conclusions about why heavyweight, document-driven processes kept producing late, wrong, or unshipped software.

The attendees arrived with competing methods. Kent Beck, Ron Jeffries, Ward Cunningham, and James Grenning brought Extreme Programming. Ken Schwaber, Jeff Sutherland, and Mike Beedle brought Scrum. Arie van Bennekum brought DSDM. Jim Highsmith brought Adaptive Software Development. Alistair Cockburn brought Crystal. Robert C. Martin, Martin Fowler, Andrew Hunt, Dave Thomas, Brian Marick, Steve Mellor, and Jon Kern brought their own practices and scar tissue.

The remarkable outcome was not that they agreed on a method. They did not, and never have. What they found was a shared set of values underneath incompatible practices. The word “agile” was chosen at the meeting to replace “lightweight,” which sounded like a euphemism for unserious. The resulting statement — four value pairs plus a concluding clause — fits on a single screen. The twelve principles were drafted in the weeks afterward and published alongside it.

Two facts about the document’s origin govern how to read it. First, it was written by practitioners reacting to specific 1990s failure modes, not as a timeless abstraction handed down from theory. Second, it had to be signable by people who disagreed about nearly everything operational, which forced it to stay at the altitude of values rather than practice. Both facts explain its most distinctive property: it tells you what to prefer, never what to do.

The Four Values and the Clause That Governs Them

Each value is a preference between two things that are both good. That structural detail is the one most often lost.

Value: X over Y	What “Y” actually refers to	What it was reacting against
Individuals and interactions over processes and tools	Methodology handbooks, mandated CASE tools, prescribed toolchains, process compliance audits	The belief that a sufficiently detailed process makes team quality irrelevant — measuring conformance instead of outcomes
Working software over comprehensive documentation	Requirements specifications, design documents, sign-off packages, traceability matrices	Projects that produced binders of approved documents and shipped nothing; progress reported in pages written
Customer collaboration over contract negotiation	Fixed-scope contracts, change-request boards, formal variation procedures	Adversarial vendor and client relationships where both parties optimized for blame allocation rather than a working system
Responding to change over following a plan	Baselined Gantt charts, phase gates, earned-value forecasts	Plans built from requirements gathered before anyone understood the problem, then defended long after they were known to be wrong

Then comes the sentence that governs the entire document:

“while there is value in the items on the right, we value the items on the left more.” — Agile Manifesto, 2001

This is the most-ignored sentence in modern software engineering. It states explicitly that processes, documentation, contracts, and plans have value. The manifesto expresses relative priority under conflict — what to give up when the two sides pull against each other — not a claim that the right-hand items are worthless.

“Agile means no documentation” is a direct misreading of that clause. So are “Agile means no plan,” “Agile means no contract,” and “Agile means no process.” The document assumes all four right-hand items exist. It only tells you which way to lean when they collide with the left-hand items. A team that writes zero documentation has not applied the manifesto; it has deleted half of it and kept the convenient half.

The Twelve Principles, Grouped by What They Are For

The principles are usually recited as a flat list of twelve, which teaches nothing. They cluster into five concerns. Paraphrased and grouped:

Cluster 1 — Deliver value continuously (principles 1, 3, 7)

Principle	Substance	Practical consequence
1	The highest priority is satisfying the customer through early and continuous delivery of valuable software	Value is delivered in slices from week one, not banked until a release date
3	Deliver working software frequently — weeks rather than months, preferring the shorter interval	Cadence is a design constraint on architecture and release engineering, not a scheduling detail
7	Working software is the primary measure of progress	Percent-complete, story counts, and document sign-offs are proxies; running code is the measurement

Principle 7 is the quiet enforcer of the whole set. If progress is measured only by working software, most forms of self-deception become impossible to sustain for more than a few weeks.

Cluster 2 — Treat change as information, not failure (principle 2)

Principle 2 welcomes changing requirements even late in development, and frames change as a source of competitive advantage rather than a defect in the requirements process. This inverts the assumption of stage-gated development, where a late change signals that Requirements Engineering failed. The Agile reading is that late change usually means someone learned something true, and a process that punishes learning will get less of it.

Cluster 3 — Build around people and conversation (principles 4, 5, 6, 11)

Principle	Substance	What it rules out
4	Business people and developers work together daily throughout the project	Requirements thrown over a wall, then a six-month silence
5	Build projects around motivated individuals; give them the environment and support they need and trust them	Staffing plans that treat engineers as interchangeable units of capacity
6	The most effective way to convey information within a team is face-to-face conversation	Specification-as-only-channel; long asynchronous ambiguity loops
11	The best architectures, requirements, and designs emerge from self-organizing teams	Architecture handed down complete by a group that will never run the code

Principle 6 has aged into the manifesto’s most contested line. It was written before distributed work was normal, and the modern reading emphasizes interaction bandwidth and latency rather than physical co-location. High-bandwidth video, shared whiteboards, and pairing tools satisfy its intent; a ticket queue as the sole channel does not. Principle 11 is also the manifesto’s strongest structural claim, and it collides directly with organizational design — see Team Topologies and Conway’s Law.

Cluster 4 — Sustain the pace and the codebase (principles 8, 9, 10)

Principle	Substance	Why it belongs in a values document
8	Sponsors, developers, and users should be able to sustain a constant pace indefinitely	Iterating forever is only possible if the team is not being consumed; crunch is an anti-pattern, not heroism
9	Continuous attention to technical excellence and good design enhances agility	Agility is a property of the codebase, not just the calendar — see Code Refactoring and Technical Debt
10	Simplicity, defined as maximizing the work not done, is essential	The cheapest feature is the one correctly declined

Principle 9 is the answer to the accusation that Agile is an excuse for sloppy work. Responding to change is only possible in a system that can be changed cheaply, which requires design discipline, tests, and refactoring. A team that skips Test Pyramid and TDD and SOLID Principles loses the ability to respond to change within a year or two, regardless of how many stand-ups it holds.

Cluster 5 — Improve the process itself (principle 12)

Principle 12 says the team reflects at regular intervals on how to become more effective, then tunes its behavior accordingly. This is the only self-modifying principle, and it is what makes the manifesto a philosophy rather than a method: the process is explicitly an output of the team, revisable by the team. Sprint Retrospective is the most common concrete implementation, but the principle does not require sprints, a facilitator, or sticky notes.

What the Document Deliberately Leaves Out

An underrated way to understand the manifesto is by its omissions. Nearly everything people argue about under the Agile banner is absent from it, and the absences were not oversights — several were actively contested at Snowbird and left out because no consensus existed.

Absent from the manifesto	Where it actually comes from	Why the omission matters
Sprints and iteration length	Scrum, XP, DSDM	Principle 3 asks for frequent delivery, not timeboxes; Kanban satisfies it with no iterations
Estimation, story points, velocity	Scrum practice and XP’s original “ideal days”	Nothing in the document requires estimating anything; see Story Points and Estimation
Roles such as product owner or scrum master	Scrum	The manifesto never assigns responsibility to a named role
Backlogs and boards	Scrum, Kanban	Ordering work is assumed; the artifact for doing so is not
A definition of “done”	Scrum practice	Principle 7 implies a bar for “working”; Definition of Done makes it explicit
Any statement about team size	Crystal and later scaling frameworks	The small-team assumption is implied by principle 6, never stated
Any statement about scaling	Scaled Agile (SAFe and LeSS)	The manifesto is silent on coordinating many teams, which is why scaling frameworks proliferated
Any mention of testing, CI, or refactoring	Extreme Programming (XP)	Principle 9 gestures at technical excellence without naming a single practice

The absence of scaling guidance is the most consequential gap. Seventeen people describing what worked for small co-located teams produced a document that says nothing about a hundred engineers on one product — and the vacuum was filled by frameworks whose critics argue they reintroduce exactly the centralized planning the manifesto opposed.

The Feedback Loop the Manifesto Assumes

Read together, the twelve principles describe one machine: shorten the loop between building something and learning whether it was right, then make the codebase and the team capable of surviving that loop indefinitely.

Everything else in Agile is an argument about how to implement that loop. Remove the loop and the ceremonies are theatre.

Why It Matters

It reframed change as information rather than defect. Before 2001, a late requirements change was treated as a process failure to be charged for. Reframing it as competitive advantage changed how contracts, budgets, and product discovery were structured across the industry.
It made “working software” the unit of progress. This single measurement standard invalidated an entire genre of status reporting in which projects were 90% complete for a year. It is the seed of CI-CD culture and continuous delivery.
It decoupled values from method, which is why it survived. Because it prescribes nothing, it outlived the specific methods present at Snowbird. Crystal and ASD faded; the manifesto did not.
It legitimized cross-functional teams. Principle 11’s claim that architectures emerge from self-organizing teams gave organizational cover to teams that owned a product end to end rather than a functional silo.
It shifted the customer from buyer to collaborator. Daily business/developer contact and collaboration over contract negotiation broke the “requirements handoff then silence” model that made most large projects unrecoverable.
It bound agility to code quality. Principle 9 is what separates the manifesto from mere speed-seeking. The ability to respond to change is an engineering property, purchased with tests, design, and refactoring.
It set a sustainability norm. Principle 8’s constant-pace clause is one of the few widely cited industry statements that treats sustained overtime as a process defect rather than commitment.
It became the vocabulary layer for a whole ecosystem. Scrum, Kanban, Extreme Programming (XP), Lean Software Development, DevOps Culture, and Scaled Agile (SAFe and LeSS) all position themselves relative to it, which makes it the shared reference point even for its critics.
Its ambiguity is both its strength and its failure mode. Prescribing nothing let it spread everywhere; it also let organizations claim the label while keeping every underlying behavior intact.

Deep Dive: Agile Is a Philosophy, Not a Methodology

This distinction is the single most useful thing to hold precisely, and the source of most confused conversations.

The manifesto contains no roles. There is no product owner, no scrum master, no coach. It contains no ceremonies: no stand-up, no planning session, no review, no retrospective. It contains no artifacts: no backlog, no board, no burndown chart, no story points. It defines no iteration length and does not require iterations at all — Kanban is a continuous-flow method and is entirely compatible with it. It cannot be “implemented,” “rolled out,” or “certified,” because there is nothing operational in it to install.

What exists is a three-layer stack. Confusing the layers produces most Agile arguments.

Layer	What it contains	Examples	Can you “do” it?
Philosophy	Values and principles; what to prefer under conflict	Agile Manifesto	No — you can only hold it or not
Framework	Roles, cadences, artifacts, explicit rules	Scrum, Kanban, Extreme Programming (XP), Lean Software Development	Yes — frameworks are adoptable
Practice	Concrete techniques, mostly framework-agnostic	TDD, pairing, CI, trunk-based development, Feature Flags, WIP limits, User Story mapping	Yes — practices are learnable

“We are doing Agile” is therefore a category error in the same way “we are doing empiricism” is. The honest sentences are “we are running Scrum,” “we use Kanban with a WIP limit of three,” or “we practice XP engineering practices inside a flow-based process.”

How the three main frameworks implement the same philosophy differently

Dimension	Agile (philosophy)	Scrum	Kanban	Extreme Programming (XP)
Nature	Values and 12 principles	Framework with fixed rules	Flow method, evolutionary	Framework plus mandated engineering practices
Prescribed roles	None	Product Owner, Scrum Master, Developers	None required	Customer, Developer, Coach, Tracker
Cadence	Unspecified	Fixed-length Sprint	Continuous flow, no iterations required	Short iterations, typically one week
Core artifact	None	Product Backlog and Refinement, Sprint Backlog, Increment	Board with explicit WIP limits	Story cards, running tested code
Change during a cycle	Welcomed (principle 2)	Sprint Goal protected; scope negotiable	Change is free at any time — just reprioritize the queue	Welcomed; stories swapped by the customer
Engineering practices	Implied by principle 9	Not specified	Not specified	Mandatory: TDD, pairing, CI, refactoring, simple design
Change model	None	Revolutionary — adopt the whole framework	Evolutionary — start where you are, change incrementally	Revolutionary — practices reinforce each other
Primary metric	Working software	Velocity and Burndown Charts	Lead time, cycle time, throughput	Running tested features

The practical payoff of keeping the layers straight: when a framework rule stops serving the values, the values win. Scrum’s rules exist to serve principle 1, not the reverse. A team that keeps a ceremony that no longer produces learning has inverted the stack — and principle 12 explicitly authorizes changing it.

Deep Dive: “Agile in Name Only” — Cargo Cult Adoption

The critique is well documented and largely fair, and it deserves stating without cynicism: the failure is usually structural rather than a matter of bad faith.

The pattern is consistent. An organization adopts the visible elements — stand-ups, two-week sprints, a board, story points, a retrospective — while leaving the load-bearing elements untouched: scope is still fixed, the date is still fixed, the plan is still made by people outside the team, and the team is still measured on conformance to that plan. Ceremonies get layered on top of a stage-gated system, and the result is often slower than what it replaced, because the team now attends meetings and files the same paperwork.

Why it happens is rarely stupidity. The visible parts are cheap and legible: you can buy training, add calendar invites, and report adoption percentages to a steering committee. The load-bearing parts require giving up control over scope commitments, changing how budgets are approved, and accepting forecasts as ranges rather than promises. Those are organizational and financial changes, not team-level ones. The ceremonies get adopted precisely because they are the part that can be adopted without anyone above the team changing behavior.

Diagnostic signals

Signal	Cargo-culted	Genuine
Scope and date	Both fixed at the start; sprints are just progress checkpoints	One is allowed to vary; scope negotiated continuously
Response to a late requirement change	Change-request process, blame, “the requirements were signed off”	Reprioritization conversation; something else drops out
The plan	Owned outside the team, defended	Owned with the team, revised on evidence
Retrospective outcomes	Same items reappear for months; nothing structural changes	Actions land, and some of them change the process itself
Estimates	Treated as commitments; used to measure individuals	Treated as forecasts; used to shape scope
Velocity and Burndown Charts	Compared across teams, targeted for growth	Used only by the team, for its own forecasting
Definition of “done”	“Dev complete,” with test and release later	Definition of Done includes shippable, tested, deployable
Documentation	Either unchanged in volume, or eliminated entirely	Reduced to what a reader actually needs, and kept current
Release frequency	Unchanged from before the transition	Measurably shorter and getting shorter

The last row is the most useful single test. If release frequency did not change, principle 3 was never adopted, and the transformation touched only the calendar. A useful second test is what happens when the team says a date is not achievable — the answer reveals whether principle 5’s “trust them to get the job done” is real or decorative.

The fair defense of the critics of Agile-as-practiced is that much of what is sold under the name genuinely is process-heavy, tool-heavy, and centrally planned — which contradicts the first value directly. The fair response is that this is a critique of the industry that grew around the document, not the document, which remains 68 words long and prescribes none of it.

The signatories became critics too

The sharpest criticism of the Agile industry has come from the people who wrote the manifesto, which is strong evidence that the critique is about implementation rather than intent. Dave Thomas argued that the noun “Agile” had been captured by consultancies and certification bodies, and proposed recovering the adjective — asking teams to be agile by taking a small step, getting feedback, and adjusting, rather than to do Agile by buying a process. Andy Hunt wrote that practitioners had been handed rigid rule sets precisely because rules are easier to sell and follow than judgment, and that following rules without context is the opposite of what the document asked for. Ron Jeffries, a co-author of XP, went as far as suggesting developers abandon the branded process entirely and keep the engineering practices, on the grounds that a bad framework imposed from above harms teams more than no framework at all.

The common thread is not regret about the values. It is that a document written to move authority toward teams became, in many organizations, a new source of authority imposed on them. That inversion — not any specific ceremony — is what “Agile in name only” actually names.

What genuine adoption costs

Real adoption is expensive in a currency most transformations are not authorized to spend. It requires that someone senior accept forecasts instead of commitments, that budgets fund teams rather than fixed feature lists, that the release pipeline be engineered until shipping is boring, and that the team be allowed to change its own process without approval. None of that is visible on a status dashboard, and all of it must come from above the team. This is why transformations driven purely bottom-up stall at the ceremony layer: the teams adopt everything within their control, and everything outside their control stays exactly as it was.

Misquotes and What the Document Actually Says

Most disputes about Agile are disputes about sentences the manifesto does not contain. A precise reading resolves them quickly.

Common claim	Status	What the document actually supports
“Agile means no documentation”	Misquote	Working software is preferred when the two conflict; documentation is named as having value
“Agile means no planning”	Misquote	Responding to change is preferred over following a plan; planning is assumed and continuous
“Agile means no estimates”	Not in the document	Estimation is never mentioned either way; the no-estimates argument is a later practitioner debate
“Agile means two-week sprints”	Framework detail	Principle 3 asks for frequent delivery; the timebox belongs to Scrum, not the manifesto
“Agile means the customer can change anything at any time”	Overreach	Change is welcomed, but principle 8 requires a sustainable pace and principle 10 requires saying no
“Agile means no architecture”	Misreading of principle 11	Architectures emerge from self-organizing teams — a statement about who decides, not whether design happens
“Agile means self-managing teams need no leadership”	Overreach	Principle 5 requires an environment, support, and trust — all of which someone must provide
“Agile is anti-process”	Misquote	Processes are named as valuable; the preference is for people when the two are in tension
“Agile does not work for regulated or safety-critical work”	Contested	The document is silent; regulated teams commonly satisfy both by producing required artifacts continuously

The test for any claim beginning “Agile means” is simple: locate it in four value statements and twelve principles. Most claims are not there, which means they belong to a framework, a consultancy, or a habit — and can be changed without abandoning anything.

Comparison

Aspect	Agile Manifesto	Waterfall Model	Lean Software Development	Scaled Agile (SAFe and LeSS)
What it is	Values and principles	Sequential process model	Principle set adapted from manufacturing	Prescriptive frameworks for many teams
Prescriptiveness	None	High: defined phases and gates	Low to moderate	Very high (SAFe); moderate (LeSS)
Planning horizon	Continuous, short	Full scope planned up front	Pull-based, demand-driven	Quarterly increments plus continuous
Attitude to change	Welcomed, even late	Controlled and costly by design	Waste to be avoided through late decision-making	Absorbed at increment boundaries
Progress measured by	Working software	Phase completion and documents	Flow efficiency, value delivered	Program increment objectives
Team scope	Silent on team size; assumes small teams	Any size, functionally organized	Any size	Explicitly multi-team, tens to hundreds
Documentation stance	Enough to be useful, less than “comprehensive”	Comprehensive and gated	Only what carries value	Substantial, by necessity of scale
Typical criticism	Too vague to act on	Too rigid for uncertain problems	Vocabulary imported from a different domain	Reintroduces the bureaucracy Agile reacted to

Real-World Use Cases

A payments team shortens its release cycle from quarterly to weekly. Principle 3 forces the engineering investment — automated deploys, Feature Flags, contract tests — that quarterly releases let them avoid. The cadence change is the forcing function, not the outcome.
A regulated medical-device team keeps full traceability and still works iteratively. They read the second value correctly: documentation is required by the regulator and therefore has value, so they produce it continuously alongside working software rather than in a pre-implementation phase.
A startup rewrites its roadmap after five customer interviews. Principle 2 is invoked explicitly to defuse the “but we committed to this in the Product Roadmap” objection; the change is treated as evidence about Product-Market Fit, not as a planning failure.
An agency replaces fixed-scope contracts with capacity-based contracts. The third value made operational: the client buys a team for a period and steers priorities continuously, instead of buying a specification and litigating variations.
A platform team cuts its stand-up because it stopped producing coordination. Principle 12 authorizes deleting a ceremony. That the ceremony came from Scrum does not make it permanent.
A distributed team reinterprets principle 6 for asynchronous work. They keep the intent — high bandwidth, low latency — by pairing on video for design decisions and reserving written specs for decisions that need durability.
A team facing a code freeze that keeps slipping adopts trunk-based development. Principle 9 in action: the branch strategy was the thing preventing frequent delivery, so agility required an engineering change, not a process change. See CI-CD Best Practices.
A legacy modernization program slices delivery by user journey rather than by architectural layer. Working software becomes measurable at month one rather than month fourteen, satisfying principle 7 on a project type notorious for defeating it.
A leadership team stops comparing velocity between squads. The metric returns to being a forecasting tool for each team, which is the only use it can bear without corrupting the estimates that feed it.

Common Pitfalls

Reading the four values as binaries. The governing clause explicitly says the right-hand items have value. “Agile means no documentation, no plan, no process, no contract” is a misquote of a document that says the opposite in its final sentence.
Treating Agile as a methodology you can install. There is nothing to install. Adopting Scrum is adoptable; “adopting Agile” is a category error that usually resolves into buying training and changing nothing structural.
Adopting ceremonies while keeping fixed scope and fixed dates. This is the defining shape of Agile-in-name-only. If both scope and date are locked before the first sprint, the sprints are progress checkpoints on a waterfall plan.
Dropping engineering discipline in the name of speed. Principle 9 makes technical excellence a prerequisite for agility. Skipping tests and refactoring buys a year of apparent speed and then removes the ability to respond to change at all.
Using velocity as a productivity target. Velocity is a team-local forecasting input derived from Story Points and Estimation. Once it becomes a target, estimates inflate, and both the metric and the forecast are destroyed.
Confusing self-organizing with unmanaged. Principle 11 says teams organize their own work, not that goals, constraints, and accountability disappear. Removing direction without providing context produces drift, not autonomy.
Letting retrospectives become ritual. If the same items recur for months with no structural change, principle 12 is not being practiced. A retrospective that cannot change the process is a status meeting with sticky notes.
Assuming Agile suits every problem. Where requirements are genuinely stable, verification is formal, and integration is physical, V-Model or Waterfall Model approaches may fit better. The manifesto was written for problems with high uncertainty and cheap iteration.
Scaling ceremonies instead of scaling the values. Multi-team frameworks can reintroduce exactly the centralized planning the manifesto reacted against. Scale the feedback loops first; add coordination structure only where it demonstrably shortens them.
Believing “responding to change” excuses never deciding. Welcoming change is not the same as having no direction. Without a goal, continuous reprioritization is just churn with a nicer name.

Scrum — the most widely adopted framework implementing these values, with fixed roles, artifacts, and a fixed-length Sprint.
Kanban — a flow-based implementation that requires no iterations at all, proving the manifesto does not mandate sprints.
Extreme Programming (XP) — the framework that takes principle 9 most seriously, mandating TDD, pairing, and continuous integration.
Lean Software Development — a parallel principle set emphasizing waste elimination and deferring decisions to the last responsible moment.
Iterative and Incremental Development — the delivery model the manifesto assumes; it predates Agile by decades.
Waterfall Model — the sequential model the manifesto was primarily written in reaction against.
Sprint Retrospective — the standard concrete implementation of principle 12.
Scaled Agile (SAFe and LeSS) — attempts to apply the values across many teams, and the most common site of the cargo-cult critique.

Example

A 40-person insurance software company announces an “Agile transformation.” Six weeks in, the visible signs are all present: every team runs a fifteen-minute stand-up, two-week sprints are on the calendar, Jira boards are configured, and everyone attended a two-day certification course. Nothing else has changed. The annual roadmap still lists 34 named features with committed quarter dates, approved by a steering committee that meets monthly. The release train still ships twice a year, gated by a four-week manual regression cycle. Teams report velocity upward, and the VP of Engineering has set a target of 15% velocity growth per quarter. Retrospectives surface the same three items every sprint — flaky test environments, unclear requirements, too much work in progress — and none of them are ever assigned an owner outside the team, because none of them are fixable inside it.

A new engineering director reads the manifesto rather than the course slides and makes three changes. First, she stops collecting velocity centrally, which removes the incentive to inflate estimates. Second, she takes one product line and negotiates with the business to unfix scope: the date for the renewals rewrite stays, the feature list becomes a ranked list, and everyone accepts publicly that the bottom of the list may not ship. Third, she funds four engineers for a full quarter on release automation and test infrastructure — an investment with no customer-visible feature attached, justified explicitly by principle 9: the team cannot respond to change while a release costs four weeks of manual regression.

The results arrive out of order. Velocity numbers get worse for two sprints as estimates deflate back to honesty. Then the renewals team ships to production in week nine instead of at the half-year gate, discovers from real usage that two of the top-ranked features are unnecessary, and drops them — a conversation that the old change-request process would have turned into a month of negotiation. Documentation volume actually goes up in one area, because underwriting rules genuinely needed a durable written specification and the team had been told that Agile forbade it; the second value only says documentation loses to working software when the two conflict, and here they never did. By quarter’s end the company is not “doing Agile” in any certifiable sense. It has one product line on a monthly release cadence, one team that can change its plan on evidence without a committee, and a retrospective whose action items now get fixed. That is what adopting the values, rather than the ceremonies, actually looks like.

Referenced by

Dig deeper

Spot an error in this note?