The Agile Manifesto is 25 years old. Time to read it again.
Agile was supposed to be an escape from bureaucracy. In many companies it became bureaucracy itself: endless stand-ups, pointless ceremonies, velocity as a KPI. This site is a reminder of what Agile really is — plus practical tools to get back there.
Snowbird, Utah · February 2001
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Projects rarely fail for lack of a tool. They fail because people don’t talk to each other. A good process supports conversation — it doesn’t replace it.
Jira as the single source of truth, conversation as “off-topic”. A process nobody may change because “the PMO decided so”.
The best proof of progress is something a user can actually touch. Documentation is valuable — as long as it helps build and maintain the product.
“We’re Agile, so we don’t write docs.” Or the opposite: a 40-page “Definition of Ready” before anyone writes a line of code.
A contract is necessary, but it can’t replace discovering together what the customer really needs. Collaboration builds trust; a contract only secures it.
A Product Owner who has never met a customer. A Sprint Review with a slide deck for executives instead of users.
A plan is a hypothesis. Markets, users and technology change faster than annual roadmaps. We plan a lot — to learn, not to dig in.
PI Planning that freezes scope for a quarter. “A change? Put it in the backlog, we’ll get to it in Q3.”
That is, while there is value in the items on the right, we value the items on the left more.
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 · Dave Thomas
© 2001, the above authors. This declaration may be freely copied in any form, but only in its entirety through this notice. Source: agilemanifesto.org.
Click a value to see what it means — and how it got broken.
What Agile is
Agile is a set of values and principles, not a specific process. It assumes that in complex work — and building products is complex — you can’t predict everything up front. So instead of one big plan, we take small steps, show results early and learn from feedback.
Scrum, Kanban, Extreme Programming and Lean are ways of living those values. You can run every Scrum ceremony and not be agile at all. You can run none of them and be very agile.
Waterfall delivers value at the end — and only if the requirements from the start are still relevant. Agile delivers piece by piece and corrects course.
The 12 principles behind the manifesto
Every card has two sides: the principle and how it gets broken in practice. Click to flip.
Where Agile came from
Agile didn’t fall from the sky in 2001. It was the result of three decades of frustration with heavy processes and experiments with lighter ones.
Winston Royce publishes a paper on managing large projects. His “waterfall” diagram becomes the industry template — even though Royce himself warned that a single-pass approach was risky and encouraged iteration.
Hirotaka Takeuchi and Ikujiro Nonaka describe “The New New Product Development Game” in Harvard Business Review: small, self-organizing teams that move the ball together like a rugby team instead of passing it on like a relay.
RAD, DSDM, Crystal and Feature-Driven Development appear. The common denominator: short cycles, closeness to the customer, less paperwork. Back then they were called “lightweight methods”.
Ken Schwaber and Jeff Sutherland present Scrum as a framework for complex products, built on empiricism: transparency, inspection, adaptation.
Kent Beck publishes “Extreme Programming Explained”. Pair programming, TDD, continuous integration, small releases. Technical discipline as the foundation of agility.
In February, 17 practitioners meet at a ski resort. They argue about methods but agree on values. They leave with a single page of text: the Agile Manifesto. A few months later the Agile Alliance is founded.
David J. Anderson starts applying Lean principles and pull systems in teams at Microsoft, and later at Corbis. In 2010 he publishes the book “Kanban”. The focus: flow and limiting work in progress.
Schwaber and Sutherland publish the first Scrum Guide. The 2020 edition is slimmed down to about 13 pages — fewer rules, more purpose: the Product Goal, and “Developers” instead of “Development Team”.
The most popular agile framework
Scrum is deliberately incomplete. It gives a minimal structure — the team chooses the rest. Click an event in the cycle to see its purpose, timebox and most common anti-pattern.
Pick an event
Every Scrum event is a chance to inspect and adapt. If a meeting doesn’t change any decision, it has stopped being a Scrum event and become a ritual.
The whole Scrum Team
Timebox up to 8 h (one-month sprint)
We agree why this Sprint is valuable (the Sprint Goal), what can be done, and how we’ll do it.
Developers
Timebox 15 minutes
Developers inspect progress toward the Sprint Goal and adapt the plan for the next day.
The container for all events
Timebox max. one month, fixed length
The rhythm in which ideas turn into value. Every Sprint is a small experiment that ends with an Increment.
Scrum Team + stakeholders
Timebox up to 4 h
We inspect the outcome of the Sprint with stakeholders and decide what’s next. A working session, not a presentation.
Scrum Team
Timebox up to 3 h
We look at how to improve quality and effectiveness: people, interactions, processes, tools, the Definition of Done.
Developers + Product Owner
Timebox ongoing activity (not an event)
We break down and clarify Product Backlog items so they’re ready to be picked in future Sprints.
Maximizes the value of the product. Manages the Product Backlog and decides on ordering.
Is not a secretary collecting requirements, nor a go-between with no authority.
Accountable for the team’s effectiveness. Teaches, coaches, removes impediments, helps the organization understand empiricism.
Is not a project manager, a meeting organizer or a “Jira admin”.
Create a usable Increment every Sprint. Plan their own work and own the quality.
Are not “resources” executing assigned tickets.
Based on the 2020 Scrum Guide (K. Schwaber, J. Sutherland), scrumguides.org.
Kanban
Kanban doesn’t change roles or add meetings. You start with how you work today and evolve your flow. The key lever: limiting work in progress (WIP).
Little’s Law puts it plainly: cycle time = work in progress ÷ throughput. Want to go faster? Do fewer things at once.
At the same throughput, cutting WIP from 12 to 4 makes cycle time three times shorter.
Agile in practice
Government
After years of trouble under a classic contracting model, the FBI’s case management system was taken in-house and finished iteratively, by a small team, in short cycles. It went live in 2012.
Short iterations and a small team can rescue a project that had already eaten its budget.
Public sector
The UK’s Government Digital Service built a single website for government services, working in discovery → alpha → beta → live phases and putting user needs first. It published its principles in an open Service Manual.
Agile works in institutions too — when you start with the user, not the procedure.
Hardware
A volunteer team built a fuel-efficient car in one-week sprints, with a modular design that let them swap parts the way you swap software components.
Iteration and modularity aren’t just for software.
Non-tech team
A campaign team visualizes its work on a board, limits the number of campaigns “in progress” and measures the time from idea to launch. Less context switching, faster results.
Kanban is the easiest place to start: show the work, limit WIP, measure flow.
Everyday life
Instead of planning everything from A to Z: bathroom first (most value), test, learn, then the kitchen. Every stage delivers something usable and teaches you something before the next one.
Delivering value iteratively is just common sense.
Your team
Smaller changes, automated tests, continuous integration and a Definition of Done that actually means something. Deployment risk drops, feedback arrives sooner.
Agility starts with technical excellence, not with yet another meeting.
Quick quiz
Eight claims you’ll hear in any open-plan office. Score: 0/0
1/8Agile means no documentation.
The manifesto says “working software over comprehensive documentation”. “Over” doesn’t mean “instead of”. We document what has value.
2/8Agile is the same thing as Scrum.
Agile is a set of values and principles. Scrum, Kanban, XP and Lean are different ways to live them. You can be agile without Scrum — and un-agile with it.
3/8The Agile Manifesto says not a single word about stand-ups, sprints or story points.
Not a word. All of these practices are tools. The manifesto is four values and twelve principles.
4/8Velocity is a good way to compare teams.
Story points are relative and local to a team. Comparing velocity only encourages point inflation.
5/8The Daily Scrum is a meeting for Developers, not a report to the manager.
The Scrum Guide is clear: the Daily is for the Developers, to plan the next 24 hours toward the Sprint Goal.
6/8In Agile, there’s no planning.
There’s a lot of planning — just more often and in smaller chunks. Planning is continuous and the plan gets updated.
7/8The team has the right to change how it works.
That’s exactly what the retrospective is for. A process that can’t be changed isn’t agile.
8/8Story points were invented to measure people’s productivity.
They were meant to help with forecasting and conversations about complexity. Ron Jeffries, often credited as one of their originators, has publicly regretted how they’re used today.
Collection
A hoodie, a cap, a mug and a sticker with the Make Agile Great Again logo. The shop opens soon.
See the collection