What does Agile actually mean?
Agile means delivering work in short cycles so you can change your mind cheaply. That is the whole idea. Everything else is machinery built to make changing your mind cheap.
The word covers a family of ways of working rather than a single one. What they share is a short loop: build a small piece, put it in front of someone who will use it, find out what you got wrong, and adjust before you have spent six months on the wrong thing. What they do not share is process. Scrum runs fixed sprints. Kanban has no iterations at all. Extreme Programming is opinionated about how you write code, which Scrum deliberately is not.
This matters because most arguments about Agile are actually arguments about one framework. Someone who says Agile does not work for their team usually means Scrum did not work for their team, and those are different claims.
What are the four Agile values?
The Manifesto sets out four preferences, each written as one thing over another. The sentence that follows them is the part people skip: while there is value in the items on the right, the authors valued the items on the left more. Nothing on the right is being thrown away.
We prefer
over
What that costs you
Individuals and interactions
Processes and tools
Less repeatability. A good team outperforms a good process, and a weak team is no longer propped up by one.
Working software
Comprehensive documentation
Less to hand over. Knowledge lives in people and in the code, so turnover hurts more.
Customer collaboration
Contract negotiation
Less certainty up front. You cannot fix scope, time and price at the start and still mean it.
Responding to change
Following a plan
Harder forecasting. Anyone who wants a date eighteen months out will not enjoy the answer.
What are the twelve principles of Agile?
The twelve principles expand the four values into working rules. They are published under a notice that allows copying only in full, so here they are grouped by what they are actually about, with the original at agilemanifesto.org.
Deliver early and often
Four of the twelve are about shipping frequently, in weeks rather than months, and treating working software as the measure of progress. Not velocity, not percentage complete, not a burndown that reaches zero.
Welcome change, even late
Two principles say changing requirements are a competitive advantage for the customer, not a failure of planning. This is the hardest one to actually mean.
Build around people
Four are about the team: motivated individuals given the environment and support they need, face to face conversation as the most effective exchange, self-organising teams, and a pace everyone can keep up indefinitely.
Keep it simple and keep improving
The last two are technical excellence and good design, and the team reflecting at regular intervals and adjusting. The reflection principle is the one that makes the other eleven correctable.
Where did Agile come from?
Agile came out of the 1990s, when several people independently built lighter alternatives to heavyweight sequential process, then met once in 2001 and agreed on what they had in common.
The sequential model everyone calls waterfall is usually traced to Winston Royce's 1970 paper on managing large software systems, which is an irony worth knowing: Royce described the strictly sequential version as risky and spent most of the paper arguing for iteration. The industry kept the diagram and lost the argument.
Through the 1990s the alternatives arrived close together. DSDM in 1994. Scrum, presented by Ken Schwaber at OOPSLA in 1995 and developed with Jeff Sutherland. Extreme Programming, which Kent Beck developed on the Chrysler C3 payroll project from 1996. Feature Driven Development in 1997. Crystal from Alistair Cockburn, and Adaptive Software Development from Jim Highsmith.
On 11 to 13 February 2001, seventeen of these people met at the Snowbird ski resort in Utah. They agreed on the word Agile over alternatives including Adaptive and Lightweight, wrote four values and twelve principles, and published them on one page. The page is still there and still unchanged.
Agile vs waterfall: what is the real difference?
The real difference is when you are allowed to learn. Waterfall puts the learning at the end, after the build, when changing anything is expensive. Agile puts it after every cycle, when changing something is cheap.
Dimension
Waterfall
Agile
Requirements
Fixed up front, signed off
Ordered up front, detailed just before build
Feedback
After delivery
After every cycle, typically 1 to 4 weeks
What is fixed
Scope. Time and cost move
Time and cost. Scope moves
Change
A change request with a cost attached
Expected, and the reason the cycle exists
Suits
Work where requirements genuinely cannot move: regulated builds, physical constraints, fixed integrations
Work where the requirements will be wrong at the start and you know it
Fails when
The requirements were wrong, which is most of the time in software
Nobody will decide what matters most, so nothing is ever finished
Waterfall is not a mistake. It is the right answer when you can actually know the requirement in advance, and the wrong answer the rest of the time.
Which Agile framework should you use?
Pick the one that matches how your work arrives. Work that can be planned in equal sized batches fits Scrum. Work that arrives unpredictably fits Kanban. Nothing else about the choice matters as much as that.
Scrum
Fixed length sprints, three accountabilities, five events. Best where work can be batched and a Product Owner has real authority to order it.
Kanban
No iterations, no prescribed roles. Visualise the work, cap what is in progress, measure how long things take. Best for support, platform and anything with unplanned arrivals.
Extreme Programming
The only one with strong opinions about engineering: pairing, test first, continuous integration, refactoring. Often run inside Scrum rather than instead of it.
Scrumban
Scrum's cadence with Kanban's flow limits. Usually where a Scrum team lands after sprints stop fitting the work.
SAFe
A scaling framework for coordinating many teams. Earns its cost where dependencies between teams are real, and adds expensive ceremony where they are not.
What does Agile look like on a real team?
On a real team it looks like a short, repeating loop with a small number of fixed meetings and a lot of ordinary work in between.
A two week cycle on a typical Scrum team: planning on Monday morning sets one goal for the fortnight and pulls in the work that serves it. Fifteen minutes each morning to re-plan the day against that goal. Somewhere mid cycle, an hour spent getting the next few items ready so planning is not a four hour argument. On the final Thursday, the team shows what it built to the people who asked for it and writes down what they said. Friday, an hour looking at how the fortnight went, ending with two or three changes that have a name against them.
That is roughly four hours of meetings in eighty hours of work. When teams say Agile is all meetings, the meetings have usually grown because the decisions are being made somewhere else and the meetings are where people find out.
Why do Agile adoptions fail?
They fail because the ceremonies change and the decision making does not. Everything else is downstream of that.
Nobody moved any authority
The team runs every event correctly and still cannot change what it is building, because that is decided annually by people who are not in the room. This is the most common failure and it is not a framework problem.
The retrospective produces nothing
If the last three retrospectives generated no change anyone can name, the correcting loop is open and the team is running the shape of Agile with none of the mechanism.
The sprint became a deadline
Cycles are a feedback rhythm. When carrying work over starts being treated as failure, teams protect the date by cutting the part nobody sees, which is quality, and the cost arrives two quarters later.
Agile was adopted to go faster
Short cycles do not make a team faster. They make a team wrong less expensively. Teams sold on speed measure speed, get velocity targets, and inflate estimates within about two months.
Is Agile still relevant?
Yes, and the interesting question is which part. The short feedback loop, continuous integration, small releases and working software as the measure of progress are now simply how most software gets built, including at companies that would never call themselves Agile.
What has aged is the ceremony. The 2001 Manifesto assumed a co-located team and an absent customer, and a lot of the machinery built on top of it since has been about scaling and coordination rather than feedback. The reasonable position in 2026 is that the principles held up better than the frameworks did.
How do you start with Agile?
Start with one team, one cycle length, and one thing you want to find out sooner than you currently do. Not a transformation.
Pick a team that owns something end to end. Agree a cycle length and do not change it for at least six cycles. Write down what done means before the first cycle, not during it. Ship something small at the end of every cycle to someone outside the team. Hold the retrospective every time, and make sure something visible changes because of it. Everything else can wait.