What Is Agile?

The problem agile responds to

Imagine Kestrel Energy decides in January to rebuild its customer portal. A traditional plan would write down every requirement first, then design, then build, then test, and deliver the finished portal some eighteen months later. That can work. It often does not, because of three things that are true of most software and much other IT work:

• Uncertainty. Nobody knows in January exactly what customers will need, which technical choices will hold, or how long unfamiliar work will take. A detailed plan built on guesses looks precise but is not.
• Late feedback. If customers first see the portal after eighteen months, every wrong assumption has been built, tested and documented before anyone finds out. Mistakes found late are the most expensive ones.
• Requirements change. Regulations change, a competitor launches an app, the business learns what it actually needs. A plan that treats every change as a deviation fights reality instead of using it.

Agile approaches answer these problems with short cycles: build a small, working part; put it in front of real users; learn; adjust the plan. The plan still exists, but it is expected to change, and the feedback that changes it arrives in weeks instead of years.

Agile is therefore best understood as a mindset and a family of approaches, not a single method: work is delivered in small, usable steps, teams and customers collaborate closely, and plans are adjusted based on frequent feedback and evidence. The word comes from the manifesto described below.

The Agile Manifesto

In February 2001, seventeen software practitioners met at The Lodge at Snowbird, a ski resort in the Wasatch mountains of Utah. They came from different "lightweight" methods — among them Extreme Programming, Scrum, DSDM, Crystal and Feature-Driven Development — and looked for what they had in common. The result was the Agile Manifesto, formally the "Manifesto for Agile Software Development": a one-page statement of four values and twelve supporting principles. Its signatories include Kent Beck, Ward Cunningham, Martin Fowler, Ron Jeffries, Ken Schwaber and Jeff Sutherland (the last two created Scrum).

The four values

The four value statements, quoted from agilemanifesto.org (© 2001, the authors of the Agile Manifesto):

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

The sentence that follows the four statements is the one most often forgotten: "while there is value in the items on the right, we value the items on the left more." The manifesto does not reject processes, documentation, contracts or plans. It says that when they conflict with the item on the left, the left wins. A team that stops writing documentation "because agile" has misread the manifesto.

The twelve principles, by theme

The manifesto is backed by twelve principles. They are paraphrased below and grouped by theme; read the original wording on the principles page.

Principle 6 dates from 2001; distributed teams today rely on video calls and chat, and the underlying idea — rich, direct conversation beats handing documents over a wall — still holds.

Iterative and incremental

Two words are used constantly in agile, often as if they meant the same thing. They do not.

Iterative development builds something through repeated cycles, each one refining the previous version based on what was learned. The first version is rough on purpose. Incremental delivery delivers a product in separate pieces that are each usable on their own, adding capability with every piece.

Two well-known analogies make the difference concrete:

• The Mona Lisa (usually credited to Jeff Patton). An incremental painter finishes the top-left corner in full detail, then the next section, and so on. An iterative painter first sketches the whole picture, then adds color, then detail. Only the iterative painter can show the whole picture early and hear "the smile should be subtler" before it is too late.
• Skateboard to car (popularized by Henrik Kniberg). If the customer needs to get from A to B, delivering a wheel, then a chassis, then a body gives them nothing usable until the car is finished. Delivering a skateboard, then a scooter, then a bicycle, then a motorcycle, then a car gives them transport — and feedback — at every step. They might even discover the bicycle is good enough.

For the Kestrel portal, "both" means the first release might let customers only view their latest bill. That is small, but it is real: customers use it, the team learns which questions they still phone the service desk about, and the next release adds what turns out to matter most.

The waterfall model

The waterfall model is a sequential way of developing a system: requirements, design, implementation, testing and operation follow each other in phases, and each phase starts when the previous one is finished and signed off. Work flows downward, like water over a series of steps.

The model is commonly traced to Winston Royce's 1970 paper on managing the development of large software systems. The irony is well known: Royce drew the sequential diagram and then argued that this simple form is risky, because testing comes last and problems found there can force a redesign. He recommended feedback between phases, early prototyping and customer involvement. The name "waterfall" was attached to the model later, by others. Read the history with some care — secondary sources tell it in slightly different ways — but the lesson holds: even the paper credited with waterfall warned against a purely one-way flow.

Waterfall-style planning is not foolish. When requirements are stable and well understood, when work must follow a fixed sequence (you cannot test cabling that is not laid), or when a regulator demands documented sign-off at each stage, planning up front is sensible. The page on predictive planning covers those techniques, and choosing an approach helps decide which fits.

What agile is not

Agile as an umbrella

Many approaches share the values of the manifesto but differ in what they prescribe:

Teams mix them freely: a Scrum team may use XP's engineering practices and a Kanban board, and a Kanban team may hold retrospectives. Larger organizations add scaling frameworks, covered in Scaling Agile.

Agile outside software

The manifesto talks about software, but its ideas travel. IT operations teams use Kanban to manage interrupt-driven work; infrastructure teams deliver network or cloud changes in small, reversible steps; marketing, HR and public-sector teams use iterations and retrospectives. Some of this works well and some of it is relabeled business as usual — results depend on whether the work really benefits from short feedback loops. Operations work has its own patterns, described in Agile in IT Operations. Agile also overlaps with ITIL's guiding principle progress iteratively with feedback and with DevOps.