Why we must stop referencing the Agile Manifesto, especially when talking about Agility in industry, and leads for a V2.[1][2]
What is the Agile Manifesto?
A) The Agile Manifesto, a sacred text?
The Agile Manifesto was written in 2001 by 17 "luminaries" of software development: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland and Dave Thomas.
It is a collective work, the product of a weekend retreat at a ski resort in Utah. Not a scientific study, not an industry standard: a consensus document among software practitioners.
B) A desire to persuade
While Agility evolves naturally through trial and error in the field, the Manifesto is a decreed conclusion. Its explicit goal: "to get software developers to adopt Agility." This is not a discovery, it is a communication act.
C) A seduction bias
The Manifesto carries three major biases:
- It froze Agility in a fixed text, even though Agility is by nature evolutionary.
- It steered Agility toward software development, creating an exclusive equivalence between the two: in most people's minds, Agility = software.
- It borrowed terms from Quality and Continuous Improvement, blurring the boundaries and making Agility hard to identify as a discipline in its own right.
D) Became a reference
Despite these biases, the Manifesto became THE canonical reference for Agility. This is strange: using a document specifically written for software as a universal reference for Agility, including outside software. Like using a guide to Romorantin to visit Naples.
E) Any positive?
Despite all these criticisms, the Manifesto has one merit: it raised the possibility of an alternative approach to traditional development. It opened a door. The problem is that it opened it onto a corridor that was far too narrow.
Can We Criticize the Manifesto?
Even within SolidCreativity, some consider the Manifesto a solid foundation. Fair enough, but right now, it is broad daylight.
Disclaimer
Yes, I dare to question the Manifesto. Why?
- Too many people think they understand Agility after reading the Wikipedia page.
- Studies on Agility outside software systematically reference the Manifesto, when they should not.
- The Manifesto focuses on project management without ever mentioning the natural agile capabilities of teams.
Critique of the Agile Manifesto
The Manifesto consists of 4 values and 12 principles. Let us examine them.
A) The 4 values
The Manifesto states that it values:
- "Individuals and interactions over processes and tools"
- "Working software over comprehensive documentation"
- "Customer collaboration over contract negotiation"
- "Responding to change over following a plan"
B) Tempting ideal or frightening one?
These values are idealistic. They paint a seductive picture, but one that does not drive adoption in business. They create an unnecessary barrier to entry: an industrial leader who reads "less process, less documentation, less contracts" sees a risk, not an opportunity. These values are not essential to Agility.
C) An Agile or a Software Manifesto?
The Manifesto always talks about software. Why use a map of Romorantin to visit Naples?
The Manifesto is NOT a reference for Agility BUT for software development.
Critique of the 4 Values
A) "Individuals and interactions over processes and tools"
- This is not specific to Agility. Any good manager has said this since the beginning of time.
- It gives the false impression that Agility does not value processes. Yet an agile team needs solid, adapted, and evolving processes.
- In industry, tools and processes are often regulatory requirements (standards, certifications). Suggesting they take a back seat is unrealistic.
- This value drives industrial leaders away from Agility instead of attracting them.
B) "Working software over comprehensive documentation"
- This value locks Agility into software development. Why mention software in a manifesto supposed to define Agility in general?
- It confuses the path with the outcome. Documentation is not the enemy; useless documentation is.
- In industry, documentation is vital: traceability, certification, safety, knowledge transfer.
- This wording gives the impression that Agility means "no docs," which is both false and dangerous.
C) "Customer collaboration over contract negotiation"
- Collaborating without a contract is the surest way to sink a company. Contracts protect both parties. You can collaborate AND have clear contracts.
- This is not a differentiator for Agility either: every healthy business seeks to collaborate with its customers.
D) "Responding to change over following a plan"
- This is THE key difference. Adapting to change rather than following a rigid plan is precisely what defines Agility.
- This single value should have been the entire Manifesto. Everything else follows from it.
Critique of the 12 Principles
1. "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."
Satisfying the customer is the goal of every business, agile or not. "Early and continuous delivery" is relevant for software shipped continuously, but unsuitable for a satellite or a drug. The word "software" anchors the statement in software yet again.
=> Generic principle disguised as an agile specificity.
2. "Welcome changing requirements, even late in development."
This is a good principle, but its wording is naive. In industry, a late change can cost millions and delay a project by years. Agility is not about welcoming every change with open arms, but about organizing to absorb inevitable changes at the lowest cost.
=> The intention is good, the wording is irresponsible outside software.
3. "Deliver working software frequently, from a couple of weeks to a couple of months."
Software again. Cycles of a few weeks are a luxury of the digital world. In aerospace, a test cycle can last 18 months. That does not mean the team is not agile.
=> Valid principle for software, inappropriate as a universal reference.
4. "Business people and developers must work together daily throughout the project."
Working "together daily"? In industry, the end customer is rarely available every day. And the "developers" are researchers, engineers, technicians. This vocabulary excludes.
=> Software-oriented principle, hard to transpose as is.
5. "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."
Wonderful. And completely universal. Any good manager would sign on the dotted line, agile or not. There is nothing specifically agile about this principle.
=> Good management practice, not Agility.
6. "The most efficient and effective method of conveying information is face-to-face conversation."
True in 2001, much more nuanced in 2025 with distributed teams and remote work. Not specific to Agility either.
=> Generic communication advice, outdated.
7. "Working software is the primary measure of progress."
Software again. And more importantly, this is wrong even in software: working software that is useless measures no progress at all. The real measure is the reduction of risk and uncertainty.
=> Wrong, even in its original domain.
8. "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely."
Good principle for avoiding burnout, but not specific to Agility. Traditional management also recommends a sustainable pace. In practice, Scrum sprints often create more pressure than the V-model.
=> Common sense advice, not an agile differentiator.
9. "Continuous attention to technical excellence and good design enhances agility."
Technical excellence strengthens everything, not just Agility. Paradoxically, this principle contradicts the image conveyed by the Manifesto itself (less documentation, fewer processes).
=> True, universal, and internally contradictory with the Manifesto.
10. "Simplicity - the art of maximizing the amount of work not done - is essential."
A fundamental principle of Lean, not of Agility. Minimizing useless work is a universal goal. No methodology recommends maximizing useless work.
=> Borrowed from Lean, presented as specifically agile.
11. "The best architectures, requirements, and designs emerge from self-organizing teams."
Self-organization is a seductive ideal, but rarely applicable as is. In industry, architectures and specifications are often constrained by standards, patents, and strategic choices. The team is not the sole decision-maker.
=> Idealistic and disconnected from industrial realities.
12. "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."
Excellent principle. But this is Continuous Improvement, a pillar of Quality since the 1950s. Deming's wheel (PDCA) was already doing exactly this.
=> Borrowed from Quality, not an Agility invention.
The Manifesto: What Role Today?
A seasoned agilist understands what lies behind the Manifesto: the spirit, the intent, the unspoken. But a traditional specialist discovering it is misled. They read "no docs, no plan, no contract" and conclude that Agility is organized chaos.
Yet Agility works in every industrial domain. Our client references demonstrate this on a daily basis. The problem is not Agility, it is its Manifesto.
The Manifesto V2 for Industry
At SolidCreativity, we have updated the 4 values and 12 principles for industry. This version is available during our Agility for Industry training courses.
Update: The V2 ultimately does not carry that name, which was deemed too presumptuous. Moreover, it is only made available to people who have attended one of our agile training courses.
[1] Pascal Jarry is founder and head of training at SolidCreativity. He has been helping industrial R&D teams transition to Agility outside software for over 15 years.
[2] This article is partly inspired by an article from the SIA (Société des Ingénieurs de l'Automobile) that fueled the initial thinking.
Want to discuss this? Contact us.
