Agile

What Agile actually is

Let us start with the most common misunderstanding, because almost everyone arrives with it. People say "we work by Agile" and mean that they have two-week sprints, a daily meeting and a board with columns. That is not what Agile is.

Agile is not a methodology. It does not tell you to hold any meeting, to use any board, or to work in sprints at all. It has no roles, no ceremonies and no artefacts.

Here is what actually happened. In February 2001, seventeen software developers met at a ski resort in Utah. They had all been working in different ways — some used a method called Extreme Programming, some Scrum, some others — and they wanted to find what those approaches had in common. Over two days they wrote a document of four sentences and twelve short principles. That document is the Agile Manifesto, and it fits on a single page.

So where do sprints and daily meetings come from? From the methodologies. Scrum, Kanban, XP and SAFe are methodologies — each one tells you concretely what to do: what meetings to hold, what roles exist, how to plan. Agile is the layer underneath them: the shared beliefs those methodologies were built on.

The four values, one at a time

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

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.

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.

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.

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. In practice that usually means fixing the time and the team while leaving the scope negotiable — the opposite of the traditional arrangement.

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 cost 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 twelve principles

Underneath the four values sit twelve principles. They are usually skipped, which is a pity — the values tell you what to prefer, but the principles are where the actual instructions hide.

They are easier to absorb in four groups rather than as a list of twelve. Here is each group, with what it asks of you in plain terms.

• Delivering value (1, 3, 7)

  Satisfy the customer through early and continuous delivery. Ship every few weeks, preferring the shorter timescale. Measure progress by working software — not by tasks closed or documents produced.

• Embracing change (2, 4)

  Welcome changing requirements even late in development. Business people and developers must work together daily — not hand over at the start and meet again at the end.

• Trusting people (5, 6, 11)

  Build projects around motivated people, give them what they need and trust them. Prefer face-to-face conversation. The best architectures and designs emerge from self-organising teams.

• Sustaining the pace (8, 9, 10, 12)

  Keep a pace you could hold indefinitely. Pay continuous attention to technical excellence. Maximise the work not done — simplicity is essential. Reflect regularly and adjust how you work.

Two of these deserve a closer look, because they are the ones teams quietly drop first.

Principle 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.

Principle 10 — "simplicity, the art of maximising 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, and it is why backlogs only ever grow.

What this looks like as a rhythm

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 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.

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.

How this shows up in real delivery

If you want to judge whether a team is genuinely agile, do not look at its board layout or count its meetings. Look at two numbers: how often it releases to real users, and how long it takes from a commit to that release.

A team running two-week sprints that releases twice a year has adopted the vocabulary but not the loop. The feedback the whole approach depends on simply never arrives — and without it, the sprints are just a reporting rhythm.

Common failure modes

• Iterations with no releasable increment — the cycle exists on the board but not in production.
• Retrospectives that produce discussion but never a single action with a name on it.
• A backlog owned by a committee, so priority is negotiated rather than decided.
• Velocity used as a performance target, which reliably inflates estimates rather than output.
• Sustainable pace quietly abandoned before every release, then never repaid.

When to use it

Related pages

• ManagementScrumScrum is the most widely used way of organising a software team. Scrum breaks work into short, fixed cycles called sprints, gives three people clear areas of responsibility, and puts a small set of regular meetings around the work so problems surface within days instead of months. This page walks through every one of those meetings — including several that real teams hold but the official guide never mentions.
• ManagementKanbanKanban is a way of managing work that starts from the process you already have and improves it under measurement. Kanban adds no roles and no sprints. It adds one rule — a cap on how many things you may work on at once — and that single constraint is what makes everything else in the method work. This page covers the board, the metrics, the seven regular meetings the method defines, and how to set that cap in practice.
• ManagementWaterfallWaterfall is a way of running a project in strict order: finish and sign off each phase before the next begins. Waterfall is usually taught as the outdated thing Agile replaced, which is both unfair and unhelpful. It is the right choice whenever changing your mind later costs more than specifying carefully now — and that is more often than its reputation suggests.