The Twelve Principles behind the Agile Manifesto
The original text as published. A condensed four-theme grouping for recall follows in §1.
We follow these principles:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity–the art of maximizing the amount of work not done–is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Source: agilemanifesto.org/principles.html — return to the Manifesto
© 2001, the above authors. This declaration may be freely copied in any form, but only in its entirety through this notice.
On the name: it’s “Agile,” not “AGILE.” It isn’t an acronym — just the adjective the 2001 group settled on. There is also no single “Agile framework.” Agile is an umbrella philosophy; Scrum, Kanban, XP and SAFe are frameworks built on top of it. Using “the Agile framework” is a mild tell that someone learned it secondhand.
1. Origins
Written in February 2001 at Snowbird, Utah by 17 practitioners reacting against heavyweight process — waterfall, RUP, CMM. The signatories included Kent Beck (XP), Ken Schwaber and Jeff Sutherland (Scrum), Martin Fowler, Alistair Cockburn, and Ward Cunningham.
The manifesto is four value statements:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Followed by the most-ignored sentence in the document:
“That is, while there is value in the items on the right, we value the items on the left more.”
Agile was never anti-documentation or anti-planning. It was a statement about relative weight.
The twelve principles
Reproduced verbatim at the top of this document. Condensed, they cluster into four themes:
Delivery 1. Satisfy the customer through early and continuous delivery of valuable software 2. Deliver working software frequently — weeks rather than months 3. Working software is the primary measure of progress
Change 4. Welcome changing requirements, even late in development 5. Business people and developers work together daily
People 6. Build projects around motivated individuals; give them the environment and support they need, and trust them 7. Face-to-face conversation is the most efficient method of conveying information 8. Self-organising teams produce the best architectures, requirements and designs
Sustainability & craft 9. Sponsors, developers and users should be able to maintain a constant pace indefinitely 10. Continuous attention to technical excellence and good design enhances agility 11. Simplicity — the art of maximising work not done — is essential 12. At regular intervals the team reflects on how to become more effective, and adjusts accordingly
Note what is absent: sprints, standups, story points, roles, boards, ceremonies. Every practice you will be asked about in an interview is a framework layered on top of this, not part of it.
2. Scrum
The framework people mean roughly 80% of the time they say “Agile.” Defined by the Scrum Guide (Schwaber & Sutherland), ~13 pages, last revised 2020.
Source: scrumguides.org/scrum-guide.html
Accountabilities
| Product Owner |
The Product Backlog and its priority order — decides what and why |
| Scrum Master |
The process; removes impediments, coaches the team. Not a project manager |
| Developers |
Building the Increment. The 2020 revision dropped “Development Team” to kill the team-within-a-team framing |
Events
- Sprint — the container. 1–4 weeks, usually 2. Fixed length; never extended to finish work
- Sprint Planning — produces the Sprint Goal; covers what and how
- Daily Scrum — 15 minutes, for the developers. Not a status report to a manager
- Sprint Review — demo the Increment to stakeholders, gather feedback
- Retrospective — inspect the process itself; commit to one or two concrete improvements
Backlog refinement (“grooming”) is an ongoing activity, not an official event.
Artifacts and commitments
| Product Backlog |
Product Goal |
| Sprint Backlog |
Sprint Goal |
| Increment |
Definition of Done |
Empirical pillars
Scrum describes itself as empirical process control resting on three pillars: transparency, inspection, adaptation. Every event exists to serve one of these.
3. Vocabulary
Terms worth being able to define cold:
- Epic — large body of work, decomposed into stories
- User story — “As a [role], I want [capability], so that [benefit]”
- Task — a unit of work within a story
- Spike — timeboxed investigation to reduce uncertainty before estimating
- Timebox — fixed duration that does not extend
- Acceptance criteria — conditions under which a story is considered complete
- Definition of Done — team-wide quality bar applying to all work
- Definition of Ready — bar a story must meet before entering a sprint
- INVEST — good story test: Independent, Negotiable, Valuable, Estimable, Small, Testable
- Story points — relative size, deliberately not hours. Usually a Fibonacci-ish scale
- Planning poker — simultaneous-reveal estimation, to avoid anchoring
- Velocity — points completed per sprint. A forecasting aid, not a productivity metric
- Burndown / burnup — work remaining over time / work completed against total scope
- MVP — smallest release that produces validated learning
On estimation: relative sizing works because humans compare better than they predict duration. Converting points back into hours destroys the entire mechanism, and is one of the most common ways teams break Scrum without noticing.
4. Kanban
Continuous flow rather than fixed iterations. No sprints, no prescribed roles, no mandatory estimation — it overlays whatever process you already have.
Source: no single canonical guide. David Anderson’s Kanban: Successful Evolutionary Change for Your Technology Business (2010) is the reference text.
Six practices
- Visualise the workflow
- Limit work in progress (WIP)
- Manage flow
- Make process policies explicit
- Implement feedback loops
- Improve collaboratively, evolve experimentally
Metrics
- Cycle time — start of work to done
- Lead time — request to done
- Throughput — items completed per unit time
- Cumulative flow diagram — reveals bottlenecks as widening bands
Little’s Law ties them together:
WIP = throughput × cycle time
This is the mathematical case for WIP limits: reducing work in progress reduces cycle time directly. It is the single most transferable idea in the whole space, and it applies whether or not you ever run a sprint.
Scrumban is the common hybrid — Scrum’s cadence and retros, Kanban’s flow and WIP limits, no story points.
5. Extreme Programming (XP)
Kent Beck’s framework, and the reason much of modern normal is normal. Where Scrum organises work, XP prescribes how you write code — they are complementary, not competing.
Source: extremeprogramming.org — the original hypertext map of the practices, maintained by Don Wells since c. 1999.
Practices: test-driven development, pair programming, continuous integration, merciless refactoring, simple design, collective code ownership, small frequent releases, on-site customer, sustainable pace, coding standards.
Associated principles: YAGNI (You Aren’t Gonna Need It) and DRY (Don’t Repeat Yourself).
Less fashionable as a named framework today, but most of it won outright.
6. Lean and other schools
Lean software development (Mary & Tom Poppendieck) ports Toyota Production System thinking into software. Seven principles: eliminate waste, amplify learning, decide as late as responsibly possible, deliver as fast as possible, empower the team, build integrity in, see the whole.
Shape Up (Basecamp) — 6-week cycles, fixed time and variable scope, “appetite” replacing estimates, deliberately no backlog, a cooldown period between cycles. Good fit for small product teams where one person can own a whole slice of work. Free to read in full at basecamp.com/shapeup.
Historic but still cited: Crystal (Cockburn), DSDM, Feature-Driven Development.
7. Scaling frameworks
- SAFe — the enterprise one. Program Increments, PI Planning, Agile Release Trains, portfolio layers. Widely adopted, widely criticised as process bureaucracy wearing Agile as a costume — framework.scaledagile.com
- LeSS — scales by removing process rather than adding it. One product backlog, one Product Owner, many teams — less.works
- Nexus — thin integration layer over Scrum for 3–9 teams — scrum.org/resources/nexus-guide
- Spotify model — squads, tribes, chapters, guilds. Worth knowing because everyone cites it, and worth knowing that Spotify have publicly stated it was an aspirational snapshot that never fully worked and that they do not run it — original 2012 Kniberg & Ivarsson paper (PDF)
8. Where the actual evidence is
The rigorous empirical work in this space is not about ceremonies — it is DevOps research. Accelerate (Forsgren, Humble, Kim) and the DORA program identified four metrics that correlate with organisational performance. Reports and guides are published free at dora.dev.
The four keys:
- Deployment frequency
- Lead time for changes
- Change failure rate
- Time to restore service
The practices driving them: trunk-based development, CI/CD, comprehensive test automation, loosely coupled architecture, and small batch sizes.
Note what is absent from that list: sprint length, story point accuracy, standup format. The delivery practices are load-bearing; the ceremony is scaffolding. If you want one defensible opinion to carry into an interview, this is it.
9. Common failure modes
Being able to name these is what separates genuine experience from having read the guide.
- Velocity as a target — textbook Goodhart’s law. Points inflate and the number stops forecasting anything. Happens the moment velocity becomes visible above the team
- Standup as status theatre — a manager collecting updates rather than developers coordinating
- Sprint as mini-waterfall — design Monday, code midweek, test Friday, ship nothing
- Retros without follow-through — the same complaints every fortnight, no action item ever landing
- Points converted to hours — destroys relative estimation entirely
- “Dark Scrum” — ceremony imposed as a control mechanism, with none of the autonomy the manifesto assumed
- Cargo-culting a scaling framework at a team size that does not need one
- Agile as an excuse for no documentation — a misreading of value statement two
10. Choosing a process
For a small team, a defensible default: Kanban with a weekly cadence. A board with WIP limits, a short weekly planning conversation, a retro every few weeks. Add ceremony only in response to a specific recurring failure, rather than adopting a framework wholesale and pruning later.
Scrum’s ceremony load starts paying off around six or more people with real coordination cost. Below that, it is largely theatre.
Hardware and deep-tech caveat: teams working against fab cycles, regulatory validation, or genuine research spikes often cannot run textbook two-week sprints, because that work does not fit the box. How a company reconciles Agile cadence with long-lead hardware or regulatory work is a genuinely good interview question — and the answer tells you a lot about how they operate.
11. Primary sources
Books
| Accelerate — Forsgren, Humble, Kim |
The only book here with real empirical backing |
| Extreme Programming Explained — Beck |
The engineering practices, from source |
| Kanban — Anderson |
Flow, WIP limits, evolutionary change |
| Lean Software Development — Poppendieck |
The Lean lineage |
12. Interview preparation
Have a two-sentence definition ready, then pivot immediately to what you actually did. Interviewers are screening for two things: that you have worked inside a team process, and that you will not fight the board.
The failure mode is answering abstractly — “Agile emphasises iterative delivery and customer collaboration” — which reads as someone who skimmed a wiki page.
What lands instead: name the ceremonies you genuinely ran, name one thing you deliberately did not do and why, and describe the feedback loop to real users. That last part separates “followed a process” from “understood why the process exists.”
Do not volunteer criticism of Scrum. If they probe — “what didn’t work about it?” — give one grounded opinion and pair it with what you would do instead. Unprompted process cynicism reads as future friction.
Questions to have an answer ready for:
- How do you handle scope changing mid-sprint?
- How do you estimate? (Ranges, with uncertainty flagged, beats a number you cannot defend)
- Tell me about a time a retro actually changed something
- How do you decide what goes into a sprint?
Ask them: how do you actually run it? A growth-stage company describing elaborate ceremony is telling you something useful.
Back to top