Agile Principles

These are the 12 principles behind the Agile Manifesto, quoted verbatim from agilemanifesto.org/principles.html. They are the reasoning underneath any specific agile framework (Scrum, Kanban, XP, …) — a framework is one way to operationalize these principles, not a substitute for them, and a team can follow a framework's ceremonies exactly while violating the principles it's meant to serve.

The 12 principles

1. "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."
2. "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."
3. "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale."
4. "Business people and developers must work together daily throughout the project."
5. "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."
6. "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."
7. "Working software is the primary measure of progress."
8. "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely."
9. "Continuous attention to technical excellence and good design enhances agility."
10. "Simplicity--the art of maximizing the amount of work not done--is essential."
11. "The best architectures, requirements, and designs emerge from self-organizing teams."
12. "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

Reading them as a group, not a checklist

• 1, 3, 7 are about the delivery cadence and what actually counts as progress: real, working software shipped frequently — not a document, a demo of a mock, or a percentage-complete estimate.
• 2 is about welcoming change rather than merely tolerating it — a process that treats a changed requirement as a problem to be managed hasn't adopted this principle even if it calls its iterations "sprints."
• 4, 6 are about communication bandwidth — daily business/developer contact and face-to-face conversation are given as the most efficient channel, which is a claim about information loss in written specs and async-only communication, not a preference for meetings for their own sake.
• 5, 11 are about where good decisions actually come from — trusted, self-organizing individuals and teams, not a plan imposed from outside the people doing the work.
• 8 is about pace, explicitly framed as sustainable and indefinite — a process that only works via a crunch before each release is violating this one regardless of its ceremonies.
• 9, 10 are about the internal quality of the work: technical excellence and deliberately maximizing work not done (a definition of simplicity worth restating precisely — it's about doing less, not about making the remaining work simple).
• 12 is the improvement loop — regular reflection that actually changes behavior, not a retrospective that produces a list nobody revisits.

Using this to evaluate a practice or process

When someone asks whether a specific practice is "agile," the useful question is which of these 12 it serves (or undermines) — not whether it matches a named framework's standard ceremony list. A daily standup that becomes status-reporting-to-a-manager, for instance, technically follows a common framework's ritual while working against principle 4 (business people and developers working together) and principle 6 (conversation as information exchange, not surveillance).

Learn more

• The 12 principles (source for this skill)
• The Agile Manifesto itself (the four values) — the shorter statement these 12 principles elaborate on.