Agile

The Manifesto in full

Here is the whole document first, because it takes two minutes to read and it is quoted far more often than it is read. Four values and twelve principles, reproduced exactly as their seventeen authors wrote them in February 2001, and numbered here so a line can be cited: "we keep breaking 2.8" is a conversation a team can have, where "we are not very agile" is a mood. Every section below refers back to these numbers.

The declaration opens: "We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:"

1. 1.The four values

   1. 1.1Individuals and interactions over processes and tools
   2. 1.2Working software over comprehensive documentation
   3. 1.3Customer collaboration over contract negotiation
   4. 1.4Responding to change over following a plan

2. 2.The twelve principles

   1. 2.1Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
   2. 2.2Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
   3. 2.3Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
   4. 2.4Business people and developers must work together daily throughout the project.
   5. 2.5Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
   6. 2.6The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
   7. 2.7Working software is the primary measure of progress.
   8. 2.8Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
   9. 2.9Continuous attention to technical excellence and good design enhances agility.
   10. 2.10Simplicity--the art of maximizing the amount of work not done--is essential.
   11. 2.11The best architectures, requirements, and designs emerge from self-organizing teams.
   12. 2.12At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

And it closes: "That is, while there is value in the items on the right, we value the items on the left more." The authors were 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. © 2001, the above authors: "this declaration may be freely copied in any form, but only in its entirety through this notice."

A layer of beliefs, not a process

Now the misunderstanding almost everyone arrives with. People say "we work by Agile" and mean that they have two-week sprints, a daily meeting and a board with columns. Read the sixteen lines above again: none of those things is in them. Agile has no roles, no ceremonies and no artefacts, and it does not tell you to work in sprints at all.

Here is what actually happened. On 11–13 February 2001, seventeen developers met at a ski resort in Snowbird, Utah. They had been working in different named ways — Extreme ProgrammingExtreme Programmingthe engineering-first agile methodAn agile methodology from the late 1990s built around engineering practices: test-first development, pair programming, continuous integration, refactoring and small, frequent releases. Much of what teams now call technical agility comes from it, and a team that adopts Scrum’s events without these practices usually watches its sprints slow down.All terms, Scrum, DSDM, Crystal, Adaptive Software Development, Feature-Driven Development, the Pragmatic Programmer books — and they wanted to write down what those approaches had in common. What they had in common turned out to be beliefs rather than practices, and it fitted on one page.

So the sprints and the stand-ups come from somewhere else: from the methodologies built on top of those beliefs. It helps to see the whole stack at once, because most arguments about "doing Agile" are really two people talking about different layers of it.

The four values, and what each one trades

Each value is written in the same shape: "A over B". Both sides are real things with real worth, and the closing sentence of the declaration says so explicitly. The claim is only about which one wins when they genuinely conflict — and they conflict regularly, which is why the document is phrased this way.

1.1 Individuals and interactions over processes and tools

A process describes what should happen. A tool records what did happen. Neither of them can resolve a disagreement about what "done" means, and neither can notice that two people have understood the same requirement differently.

The practical version of this value is: when something goes wrong, look at the conversation before you look at the workflow. A team that responds to every problem by adding a mandatory field to the ticket template is doing the opposite of what this value asks.

1.2 Working software over comprehensive documentation

This is the value most often misread as "do not write documentation". It says nothing of the sort. It says that when you have to choose where the next hour goes, working software is the more honest measure of progress — which is exactly what line 2.7 then states as a principle.

The reason is that documents can be completed while the product does not work, and that gap can hide for months. A 200-page specification signed by everyone tells you what people believed in March. A working feature tells you what is true today.

The useful test for any document: does it unblock a specific person doing a specific thing? An architecture decision record that stops the next engineer re-litigating a choice is work. A status document nobody opens is inventory.

1.3 Customer collaboration over contract negotiation

A fixed-scope contract turns every new discovery into a dispute. The client wants something the contract does not cover; the supplier is entitled to refuse or to charge; both sides now spend energy on the boundary instead of on the product.

Collaboration does not mean working without a contract. It means structuring the agreement so that changing direction is a normal decision rather than a breach. The diagram shows the move that makes that possible: the project triangle turned over.

A plan-driven project fixes the scope and estimates time and cost from it. An agile one fixes the team and the dates, which fixes the cost, and lets the scope be the thing that moves — ordered by value, so that what falls off the end is the least valuable item rather than whatever happened to be scheduled last.

In contract terms the choice usually lands between a fixed pricefixed priceagreed scope, agreed sumA contract where an agreed scope is delivered for an agreed sum, so the supplier carries the cost of anything that takes longer than planned. That is why fixed-price work comes with the strictest change control: every change to the scope is a commercial event, not just a planning one.All terms, which fixes the scope and turns every discovery into a change requestchange requesta formal request to change something agreedA formal request to change something already agreed — the scope, a design, a live system — which is assessed for its effect on cost, time and risk, and approved or rejected before any work starts. It is how a signed baseline absorbs new information; treated as a failure rather than as information, it becomes the way a plan is defended past its usefulness.Full article →All terms, and time and materialstime and materialspaid for the hours spentA contract where the client pays for the time actually worked rather than for a fixed scope, so changing direction costs money instead of a renegotiation. The risk moves to the client, which is why this model comes with more reporting and a harder conversation about what the hours bought.All terms, which pays for the team’s time and leaves the order of work to the customer. Agile work fits the second far more naturally. A common middle path is a fixed budget per iteration, with the scope agreed afresh at every review — the customer can stop after any iteration and keep what works.

1.4 Responding to change over following a plan

A plan is a hypothesis about the future written with the information available on the day it was made. That is not a criticism — it is simply what a plan is. The question is what happens when new information arrives.

Holding to the plan after the evidence has changed is not discipline. It is the sunk costsunk costmoney already spent and goneMoney already spent that no decision can recover. A decision to carry on should compare only the cost still to come with the alternatives; letting what is already spent argue for finishing is the sunk-cost fallacy, and it keeps failing projects alive for years.Full article →All terms fallacy with a project schedule attached. This value asks you to treat re-planning as the expected outcome of learning something, not as an admission that the original plan was incompetent.

The bet underneath: change must be cheap

Line 2.2 welcomes changing requirements "even late in development". That only makes sense under one condition: a late change must not cost much more than an early one. Notice what kind of condition that is. It is an assumption about your code, your tests and your release process — not about your meetings.

The classic view, set out by Barry Boehm in 1981, is that the cost of a change multiplies with every phase already built on the old decision. A requirement found to be wrong during testing means redoing the design, the code and the tests that were built on it. Kent Beck’s counter-claim in 1999, for Extreme Programming, was that the curve can be kept nearly flat — with automated tests, continuous integration, refactoring and simple design.

Agile planning is a bet on the flat curve. It deliberately defers decisions and invites late change, and that only pays if late change is cheap. Look at the red ring on the diagram: iterative planning on a code base with no tests. That is the worst of both worlds — a process that invites exactly the changes the code makes expensive. Notice too that the flat curve starts a little higher: the tests and the refactoring are paid for every day, and that daily cost is the price of keeping a late change cheap.

This is why line 2.9 is not decoration. "Continuous attention to technical excellence and good design enhances agility" is the precondition for everything else on the list. A team that adopts the meetings and skips the engineering has bought the invitation to change without the ability to afford it.

Agile next to Waterfall

The two are usually presented as new versus old, which is not a useful framing and is not accurate either. They are two different bets about the same thing: how expensive it is to change your mind later.

Read the last row of each column together, because that is the whole argument. If changing your mind late is cheap — a web service with automated tests and continuous deployment — deferring decisions costs you almost nothing, so iterate. If changing your mind late is genuinely expensive — firmware on shipped hardware, a certified medical device — then specifying carefully up front is the rational choice, not an outdated one.

Loops, not phases

Agile itself prescribes no cycle. But the most common way teams put these principles into practice is an iteration: a short, repeating loop that ends with something usable. The diagram below shows the shape most delivery teams would recognise.

Notice that the loop closes. That is the entire mechanism. Each pass through it produces something real, someone reacts to it, and the reaction changes what happens on the next pass. Remove the closing — ship at the end instead of every iteration — and the loop becomes a schedule with meetings in it.

The iteration is only the middle of the picture, though. Extreme Programming drew itself as a set of nested feedback loops, from a pair correcting a line in seconds to a release reaching users. Each loop is defined by the question it can answer and by how long one full turn takes.

Read the diagram from the bottom. Only the release to real users can tell you whether the product changed what they do — every loop above it answers a narrower question about the code or the plan. And that is the loop teams most often leave open. A team with two-week sprints and quarterly releases learns about its users four times a year, whatever its board says, which is exactly why line 2.3 prefers the shorter timescale.

The cadence matters more than the ceremony. A two-week iteration that ends with something deployable teaches you more than a four-week one that ends with a demo of unmerged branches.

Twelve principles, twelve tests

The values tell you what to prefer. The principles are where the actual instructions hide, and each one can be turned into something you could observe in your own team within a week. Each one also has a counterfeit: a practice that looks like it from a distance and does the opposite.

Two of these deserve a closer look, because they are the ones teams quietly drop first. Line 2.8 — sustainable pace — says the team should be able to maintain its speed indefinitely. Not "work hard for this release", but a pace that could continue for years without anyone burning out. A team that hits its dates through a fortnight of overtime has not gone faster; it has borrowed capacity from next month.

Line 2.10 — "the art of maximizing the amount of work not done" — is the most quietly radical sentence in the document. It says that deciding not to build something is a form of progress. Most teams have no mechanism for that at all, which is why backlogs only ever grow.

Six programmes, and the line each one tested

Four of these six are public programmes, and that is not because governments fail more often. It is because governments publish their audits. Private projects fail in the same shapes and leave fewer documents behind.

Where it degrades into theatre

The honest limit first: the evidence for Agile is weaker than its marketing. The most quoted numbers — agile projects succeeding several times as often — come from the Standish Group’s CHAOS reports. In 2010 Eveleens and Verhoef applied the Standish definitions to 1,211 real projects and showed that those definitions measure how a forecast was biased, not whether a project succeeded. The claim that survives is narrower: where change is cheap and users are reachable, short loops find mistakes while they are still cheap. Agile cannot make a change cheap or a customer available.

The sharpest critics are among the authors. In March 2014 Dave Thomas, one of the seventeen, wrote that "agile" had become a noun to be sold — certifications, tools, consultants — and argued for keeping the adjective instead. In May 2018 Ron Jeffries, another signatory, told developers to abandon what was being imposed on them under the name. When two of the authors say the word has been captured, the useful move is to stop arguing about the word and look at the loops.

• SprintsSprinta fixed-length work cycleA fixed period, usually one to four weeks, at the end of which there is something finished enough to show. The length is fixed and the scope moves — a sprint that is extended to fit the work has given up the only thing it was for.Full article →All terms, a board and a stand-up, with releases still quarterly — the vocabulary without the loop (2.3).
• "Agile" used to mean no plan, no documentation and no contract, as if the right-hand side of the values were worthless.
• An agile transformation that fixes scope, date and budget at the start and calls the rest agile.
• Iterations with no working increment — the cycle exists on the board, not in production (2.7).
• VelocityVelocityhow much fits in a sprintHow much a team actually completes in a sprint, averaged over several. It is a planning aid for that one team and nothing else — comparing the velocity of two teams, or setting it as a target, reliably produces inflated estimates rather than more work.Full article →All terms or story pointsstory pointsrelative size, not hoursA unit for estimating the relative size of backlog items — an 8 is roughly twice a 5 — deliberately not tied to hours. They are useful for one team’s planning and nothing else: turned into a target or compared across teams, they inflate instead of measuring.Full article →All terms used as a performance target, which reliably inflates estimates rather than output.
• RetrospectivesRetrospectivethe meeting that changes the processThe regular meeting where a team examines how it works and changes one thing. A retrospective that ends without a named change someone owns is a complaint session, and teams stop attending it for good reason.Full article →All terms that produce discussion but never an action with a name on it (2.12).
• Sustainable pace abandoned before every release and never repaid (2.8).
• A backlog that only grows, with no mechanism for deciding not to build (2.10).
• Another company’s org chart adopted as a model, without the reflection that produced it (2.11, 2.12).
• Certificates and tooling counted as adoption, while nothing reaches users any sooner.

When to use it

Related pages

• ManagementScrumScrum is a framework in which a team of ten or fewer ships a usable increment in fixed cycles of a month or less, called sprints, and adapts at five set events. It defines three accountabilities, three artefacts and those five events, and deliberately nothing about engineering. The page opens with the whole framework on one screen — every event with its timebox, who attends and what it produces — then covers the theory it rests on, each event in order along with the four meetings real teams add, the accountabilities and why the limit is ten, the Definition of Done and what happens when it stops short, five documented episodes, and where it degrades.
• ManagementKanbanKanban is a way of managing work that starts from your current process and improves it by limiting work in progress and measuring how that work flows. It adds no roles and no sprints. The page opens with every element of a Kanban system on one screen — what a team writes down and what its absence looks like — then covers why a board alone is not Kanban and the two bodies that define the method, its six principles and six practices, the four flow measures and the arithmetic under them, forecasting from history instead of estimates, the seven cadences, five documented cases, and where it degrades.
• ManagementPM Checklist for a New ProjectA project manager’s first ninety days on a project they did not start is a diagnosis followed by a small number of deliberate changes, not a reorganisation. Month one is for finding out how the work actually flows, month two for agreeing what you will change and with whom, month three for making the first changes land and being able to show what they moved. This page is that checklist, with the situational judgement that decides which parts of it apply to you.