The Agile Manifesto is 25. It was mostly right.

The Agile Manifesto is 180 words. Fewer than half of them are the four values themselves. The rest is a clarification: the authors value processes, documentation, contracts, and plans. They just value the things on the left more.

In February 2026, seventeen of the original signatories gathered at a Thoughtworks retreat in Utah to mark the 25th anniversary. Accounts from the event describe healthy disagreement. Several signatories said they hadn't anticipated the certification industry. One noted that if a two-day course delivers a Certified Scrum Master credential, the word master is carrying a heavy load.

That gap, between the document and the industry that grew from it, is what this piece is about.

What the manifesto actually says

Most engineers who have spent years doing agile have never read the original document. They have read the Scrum Guide, or a SAFe whitepaper, or a corporate training deck. Those are derivative products, not the manifesto.

The manifesto states four values and twelve principles. Every value is a preference, not a prohibition. The phrasing is 'individuals and interactions over processes and tools' — not 'instead of processes and tools.' Every misuse of the manifesto as a reason to skip documentation, contracts, or planning ignores that word.

The twelve principles are more specific: small, motivated teams; sustainable pace; continuous delivery of working software; technical excellence as a prerequisite for agility. None of them specify two-week sprints, story points, or sprint reviews. Those are Scrum conventions. The manifesto predates Scrum's widespread adoption.

Three values that aged well

'Working software over comprehensive documentation' is still the right call. Teams that spent 2022 and 2023 writing exhaustive requirements documents for LLM integrations that didn't yet exist fared worse than teams that shipped early and updated their documentation to match what they learned. The priority ordering holds.

'Customer collaboration over contract negotiation' is harder to practise in enterprise contexts where procurement instincts push toward exhaustive statements of work. But teams that stay in close contact with the people using what they build catch misalignments far earlier than teams waiting for formal review cycles. The instinct is correct.

'Responding to change over following a plan' looks prescient from 2026. The pace at which what's buildable changed between 2022 and 2025 was significant: LLMs, then agents, then agentic tooling wired directly into development environments. Teams with practice at reorienting quickly navigated those shifts better than teams locked into multi-year roadmaps. Planning is still useful. The value is about priority, not about abandoning plans entirely.

The value that got complicated

'Individuals and interactions over processes and tools' is more complex in 2026 than it was in 2001.

The tools have changed in kind, not just degree. A developer working closely with Claude or Cursor is not exactly an 'individual' in the sense the manifesto had in mind. The interactions now include non-human collaborators. The manifesto's framing didn't anticipate this, and it would be odd to pretend otherwise.

The underlying principle still holds: the people doing the work, and their conversations with each other and with customers, matter more than any particular methodology. The specific framing needs updating. AI coding tools can substitute for human judgement, which is exactly what the value was cautioning against. Used well, they extend it. The distinction matters.

What the implementation industry built

The short version: the manifesto said to prefer people over process. The transformation industry built a process to get you to prefer people over process.

Scrum is not in the manifesto. Two-week sprints are not in the manifesto. Story points, velocity charts, burn-down charts, and sprint reviews are not in the manifesto. They are Scrum conventions. Scrum is one implementation framework. It is not the definition of agile.

The daily standup appears in the manifesto as: 'The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.' The manifesto does not describe a 15-minute session at 9:30 every morning where people report task status to a Scrum Master. The distance between those two things is where a generation of wasted meeting time lives.

SAFe is a separate category of problem. The Scaled Agile Framework adds program increments, PI planning events, Agile Release Trains, and a portfolio layer. One of the manifesto's twelve principles reads: 'The best architectures, requirements, and designs emerge from self-organising teams.' SAFe's portfolio governance sits in direct tension with that principle. Large organisations genuinely need coordination mechanisms. Calling those mechanisms agile without acknowledging the trade-off is where the problem starts.

The certification industry added its own layer. A two-day course produces a Certified Scrum Master credential. The word certified implies an objective competency standard. The standard is completion of two days of training. Neither the manifesto nor its authors proposed certification as a mechanism for spreading the ideas.

AI development and the manifesto's original intent

There is a quiet irony in where AI-assisted development has landed.

A team using AI coding tools well looks, in several respects, more like what the manifesto's authors had in mind than a team running SAFe. Developers working with AI coding assistants produce working software quickly. Iteration happens in minutes, not sprints. The feedback cycle between idea and running code is tight. Documentation tends to emerge from the code rather than preceding it.

The agile transformation industry pushed organisations toward more process as they scaled. AI tooling is pushing individual developers toward less process because the friction that justified the process is lower. Continuous delivery without ceremony isn't a new idea. It lives in the original extreme programming principles from which the manifesto grew. AI coding tools are making it cheap enough to practise again.

What taking the manifesto seriously looks like in 2026

A team that takes the original document seriously, rather than the industry built around it, does a few specific things.

It ships continuously. Not 'whenever it feels ready' and not 'at the end of each sprint.' Small things, often, because working software is the primary measure of progress. When that cadence is not achievable, the team looks at the bottleneck: test coverage gap, deployment pipeline problem, coordination overhead, and removes it rather than normalising the constraint.

It talks to customers directly and regularly. Not through a Product Manager who attended the sprint review. Someone who builds the software should be in regular contact with people who use it. Not a quarterly customer advisory board. Actual conversations, often.

It reflects on process but does not perform reflection. A retrospective is useful only if the team acts on what it surfaces. A standing retrospective that surfaces the same complaints every two weeks, without changes, is ritual, not practice.

It plans at the granularity where planning is useful. Near-term work gets detailed plans. Anything more than six weeks out gets rough estimates the team expects to revise. 'Responding to change over following a plan' does not mean no planning.

Most of what makes this hard has nothing to do with methodology. Organisational incentives that reward predictability over accuracy, and management instincts that conflate visibility with control, are the actual constraint. The manifesto didn't solve those problems. Read the 180 words and it is clear the authors knew exactly what they were and weren't doing.