What are the 12 agile principles?
The 12 agile principles are the statements published alongside the Manifesto for Agile Software Development in 2001 [1][2]. The manifesto gives four values; the principles explain how a team puts those values into practice day to day. They are written for software teams, but most of them apply to any work where requirements change and value is delivered in stages.
Knowledge Train’s illustrated version above gives each principle a two word heading, such as Welcome change or Reflect and adjust. Those headings are Knowledge Train’s own summaries [4]; the wording below is the official text from agilemanifesto.org [1].
The 12 principles and what they mean in practice
- Satisfy the customer. “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Value reaches the customer in pieces, starting early, rather than in one release at the end.
- Welcome change. “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.” A change of plan is treated as new information, not a failure of planning.
- Deliver frequently. “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” This is where short iterations, called sprints in Scrum, come from.
- Work together. “Business people and developers must work together daily throughout the project.” The people who know what is needed and the people building it stay in contact all the way through, not only at sign-off.
- Trust and support. “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” Managers remove obstacles rather than direct every task.
- Face-to-face conversation. “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” Written in 2001, before video calls were normal; many remote teams now read it as “talk directly rather than through documents and tickets”.
- Working software. “Working software is the primary measure of progress.” A finished, usable feature counts; a completed design document or a percentage estimate does not.
- Sustainable pace. “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” Regular crunch time is a warning sign, not a badge of commitment.
- Technical excellence. “Continuous attention to technical excellence and good design enhances agility.” Clean, well tested code is what lets a team change direction quickly later.
- Simplicity. “Simplicity, the art of maximizing the amount of work not done, is essential.” Build the smallest thing that meets the need and leave out features nobody has asked for.
- Self-organising teams. “The best architectures, requirements, and designs emerge from self-organizing teams.” The team decides how to do the work, rather than having a design handed down.
- Reflect and adjust. “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” In Scrum this is the retrospective at the end of each sprint.
One small correction to the graphic: its tenth quotation drops the first word, “Simplicity”, which is the point of the principle. The other eleven quotations match the manifesto word for word [1].
The 4 agile values behind the principles
The manifesto itself is only four lines. Its signatories say they value [2]:
- individuals and interactions over processes and tools
- working software over comprehensive documentation
- customer collaboration over contract negotiation
- responding to change over following a plan
It adds that while there is value in the items on the right, they value the items on the left more [2]. That last sentence is often missed. Agile does not mean no documentation, no plan or no contract; it means those things serve the work rather than replace it. Knowledge Train puts it simply: the values give a general sense of what being agile means, and the principles give examples of how agile should be put into practice [4].
Where the Agile Manifesto came from
On 11 to 13 February 2001, seventeen people met at The Lodge at Snowbird ski resort in Utah. They included representatives of Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development and Pragmatic Programming, all methods that pushed back against heavy, document-driven ways of building software. They agreed the manifesto and named themselves the Agile Alliance [3]. The Agile Alliance still publishes the 12 principles as part of its introduction to agile [5].
How the principles are grouped
Twelve statements are a lot to hold in your head, so trainers usually group them. Knowledge Train’s summary works as a set of themes [4]:
- Customer value: deliver a usable product early and improve it through frequent small releases (principles 1 and 3).
- Change: welcome it, even late on (principle 2).
- People: business and developers working together daily, motivated individuals, direct conversation and self-organising teams (principles 4, 5, 6 and 11).
- Progress and pace: measure progress by working software and keep a pace you can sustain (principles 7 and 8).
- Quality: technical excellence, good design and simplicity (principles 9 and 10).
- Improvement: regular reflection and adjustment (principle 12).
Agile principles and Scrum
Scrum, one of the methods represented at Snowbird [3], is the most common way teams turn the principles into a routine. Fixed-length sprints put principle 3 into practice, the sprint review shows working software to stakeholders (principles 1, 4 and 7) and the retrospective is principle 12 on the calendar. The principles themselves do not prescribe any of these ceremonies, though. A team can follow Kanban or its own process and still be agile if it delivers often, works closely with the customer and keeps improving.
Questions about the agile principles
What are the 12 principles of agile?
In short: satisfy the customer, welcome change, deliver frequently, work together daily, trust and support motivated people, talk face to face, measure progress by working software, keep a sustainable pace, pay attention to technical excellence, keep it simple, rely on self-organising teams, and reflect and adjust regularly [1].
What are the 4 agile values?
Individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan [2].
When was the Agile Manifesto written?
It was agreed on 11 to 13 February 2001 by seventeen people meeting at Snowbird ski resort in Utah [3].
What is the most important agile principle?
The manifesto itself names one: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software” [1]. The other eleven support that aim.
What does “maximizing the amount of work not done” mean?
It is the tenth principle on simplicity [1]. It means avoiding work that adds no value, such as features nobody needs, reports nobody reads or over-engineered designs, so effort goes on what the customer will use.
Sources
- Agile Manifesto, Principles behind the Agile Manifesto.
- Agile Manifesto, Manifesto for Agile Software Development.
- Jim Highsmith for the Agile Alliance, History of the Agile Manifesto.
- Simon Buehring, Knowledge Train, Agile principles, the creator’s page with this infographic.
- Agile Alliance, 12 Principles Behind the Agile Manifesto.
Last reviewed 2 November 2026
