Published in 2001, the Agile Manifesto fits in four values and twelve principles. Twelve years later, it remains the compass of every serious team. Here is the full text, with a few words on what it really means.
In February 2001, seventeen software development practitioners gathered at a ski resort in Snowbird, Utah. They weren't trying to found a movement. They were simply trying to find common ground between their respective methods — XP, Scrum, DSDM, Crystal, Feature-Driven Development. What they wrote that weekend fits on a single page. It has since been called the Manifesto for Agile Software Development.
Twelve years later, this text is cited everywhere and applied nowhere — misunderstood, reduced to a buzzword. It's time to read it in full.
The four values
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
That is, while there is value in the items on the right, we value the items on the left more.
The last sentence is the most overlooked. The manifesto does not say that processes, documentation, contracts and plans are useless. It says that when you have to choose, you choose the left over the right. It's a matter of priority, not abolition.
The twelve principles
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Not "satisfy the customer by delivering what was planned". Value takes precedence over adherence to the initial scope.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Late change is not a planning failure — it is an opportunity. Markets move. Users learn. Teams that can pivot win.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Delivery frequency is not an organizational constraint, it is a deliberate choice to shorten feedback loops.
Business people and developers must work together daily throughout the project.
Not "hold a kick-off meeting then send emails". Daily. It's radical, and intentional.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Trust is not a management bonus, it is a prerequisite for functioning. Micro-managed teams don't deliver good software.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Specification documents don't replace conversation. The Jira ticket doesn't replace a quick discussion in front of a whiteboard.
Working software is the primary measure of progress.
Not story points. Not closed tickets. Not intermediate deliverables. Software that runs. That's the only yardstick that matters.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
The marathon sprint is not agile. A team that finishes exhausted after every iteration is not agile. Sustainability is a technical virtue, not a comfort.
Continuous attention to technical excellence and good design enhances Agility.
Technical debt is not the price of velocity. It is its enemy. Poorly written code slows everything that follows.
Simplicity — the art of maximizing the amount of work not done — is essential.
YAGNI. KISS. Don't build what you don't need right now. This is harder than it sounds.
The best architectures, requirements, and designs emerge from self-organizing teams.
Architecture doesn't flow down from a chief architect to the implementation team. It emerges from the people building the software, because they are best placed to do so.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
The retrospective is not a formality at the end of a sprint. It is the mechanism by which a team learns. No serious retro, no real improvement.
What this text is not
The Agile Manifesto is not a guide for deploying Scrum. It mentions neither sprints, nor story points, nor daily standups, nor backlogs. These practices have their value — some more than others — but they are not the manifesto.
It is also not a promise that your projects will go faster. It says you will deliver value sooner, learn faster, be able to adapt. Raw speed is not the goal.
What it is, is a clear stance on what matters in software development: people, working product, collaboration, and the ability to change. Everything else is secondary.
The original manifesto text is available at agilemanifesto.org.