Agile software development: what the manifesto actually says

Agile is not a methodology. It is a 2001 manifesto of four value statements and twelve supporting principles, written by seventeen people who had each arrived at similar conclusions about why software projects failed. Scrum, Kanban and XP are methodologies; agile is the set of ideas they share.

The four values

Each is a preference, not a rejection. The original text is explicit that the items on the right have value — the claim is only that the items on the left have more.

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Almost every misuse of the word comes from dropping the second half. "We're agile, so we don't write documentation" is not what the manifesto says.

The principles that carry the weight

Twelve principles sit behind the values. Four do most of the work:

• Deliver working software frequently, from a couple of weeks to a couple of months. The shorter the interval, the sooner you find out you built the wrong thing.
• Welcome changing requirements, even late. This is a claim about economics: the cost of change should be flat rather than rising steeply, which requires test coverage and a design that tolerates it.
• Working software is the primary measure of progress. Not documents produced, not story points burned.
• At regular intervals the team reflects and adjusts. The one principle that makes the others self-correcting — and the first to be dropped when a team is busy.

Scrum and Kanban are not the same thing

Scrum

Time-boxed iterations, typically two weeks. Work is committed to at the start of a sprint and the scope is held stable within it. Three roles — product owner, scrum master, developers — and four events: planning, daily scrum, review, retrospective.

Scrum suits work that can be predicted a fortnight ahead. It fits support and operations badly, because the sprint commitment is broken by every urgent interruption.

Kanban

Continuous flow, no iterations. Work is pulled when capacity frees up, and the central mechanism is the work-in-progress limit: a column may hold only so many items, so finishing something is the only way to start something.

Kanban suits unpredictable arrival rates. It is also far easier to adopt incrementally, because it starts by visualising the process you already have rather than replacing it.

Where it goes wrong

Ceremonies without the values

The most common failure. A team holds a daily stand-up that is a status report to a manager, a retrospective whose actions are never done, and a sprint whose scope is changed mid-flight — then concludes agile does not work. What did not work was the ritual, performed without the thing it was meant to enable.

Velocity used as a target

Velocity is a planning aid: how much this team completed recently, useful only for forecasting this team's next few weeks. The moment it becomes a performance measure, estimates inflate, and it stops measuring anything. Comparing velocity between teams is meaningless, since points are not a shared unit.

No technical practices underneath

"Welcome changing requirements late" is only affordable if changing code is cheap. Without automated tests, continuous integration and attention to design, iterating simply accumulates defects faster. Extreme Programming bundled these practices with the process for exactly this reason, and dropping them is why some agile adoptions produce worse software more quickly.

Fixed scope, fixed date, fixed budget

If all three are fixed by contract, the team cannot respond to change, and the process is waterfall with stand-ups. The honest options are to vary scope or to vary the date.

When it is the wrong choice

Iterative delivery assumes cheap iteration and a customer available to give feedback. Where neither holds — regulated medical devices, aerospace, anything where a release requires certification, or a fixed-price contract with a fixed specification — the up-front approach exists for real reasons. Hybrid arrangements, with agile development inside a staged delivery framework, are common and legitimate.