The original Agile principles: what they ask teams to optimise
A practical reading of the twelve principles behind the 2001 Agile Manifesto: early value, useful feedback, technical quality, sustainable teams and adaptation without ceremony for its own sake.
The principles came before the modern Agile industry
In February 2001, seventeen software practitioners met at Snowbird, Utah, looking for common ground between approaches including Extreme Programming, Scrum, DSDM, Crystal and Feature-Driven Development. They produced four value comparisons in the Manifesto for Agile Software Development and a supporting set of twelve principles.
The principles are not a delivery framework. They do not prescribe sprints, story points, stand-ups, ticket states or particular job titles. They describe what a software team should optimise: useful outcomes, short feedback loops, close collaboration, trustworthy engineering and the ability to adjust.
That distinction matters because a team can perform every familiar ceremony while working against the original intent. A full backlog does not prove that customers receive value. A sprint boundary does not make a release frequent. Calling a meeting a retrospective does not mean the organisation permits anything to change.
1. Deliver useful software early and continuously
The first principle puts customer value ahead of internal activity. Progress begins when a usable capability reaches the people it is meant to help, not when requirements, designs or code pass between departments.
Early delivery exposes mistaken assumptions while there is still time to respond. Continuous delivery of value does not mean releasing every commit to every user. It means keeping changes small enough, verified enough and operationally ready enough that the organisation can release when the product needs it.
A team applying this principle asks what the smallest useful outcome is and how soon it can observe real use. A technical platform change can still be valuable, but the connection to reliability, delivery speed or an enabled product outcome should be explicit.
2. Treat changing requirements as information
The second principle accepts that understanding changes during development. Users encounter the product, markets move and technical constraints become visible. A late discovery is not automatically a failure of discipline; it may be evidence that improves the result.
Welcoming change does not mean accepting unlimited scope without discussing cost. The team still needs a clear product direction and an ordering mechanism. The practical response is to make the effect of a change visible, replace a lower-value assumption and preserve the ability to alter the system safely.
Architecture, contracts and funding models can either support this or make every discovery punitive. Short planning horizons, modular boundaries, automated tests and compatible data changes reduce the price of learning.
3. Put working software into use frequently
The original principle preferred delivery on a scale of weeks rather than months. Its purpose is feedback. Small increments shorten the distance between a decision and evidence about whether that decision was useful and technically sound.
A two-week iteration that produces a large unreleased batch every quarter has a short planning cadence but a long delivery cadence. Conversely, a team may release several times a day without using Scrum at all. Frequency is about the path to users, not the calendar used to organise meetings.
Measure the time from a committed change to safe production use, the size of releases and how often a release must be delayed or rolled back. Those signals reveal more about this principle than sprint velocity.
4. Keep product and engineering decisions close together
Daily collaboration between business and development was a direct rejection of long hand-offs. The people who understand users, commercial constraints and software behaviour need a shared decision loop throughout the work.
This does not require one product representative to attend every engineering conversation. It requires prompt access to decisions, shared examples of expected behaviour and joint ownership of trade-offs. Engineers should understand why an outcome matters; product specialists should understand material cost and risk.
A requirements document can support collaboration but cannot replace it. If ambiguity takes a week to cross an organisational boundary, the team will either wait or build from an assumption. Both lengthen feedback.
5. Support capable people and trust them to deliver
The fifth principle joins autonomy with environment and support. Telling a team to take ownership while central approval queues, unstable tooling or unrealistic commitments control every decision is delegation in name only.
Trust is not the absence of accountability. Give a team a clear outcome, relevant constraints, access to users and production evidence, then let the people closest to the work decide how to proceed. Review results and risks rather than prescribing every implementation step.
Motivation is also shaped by the system around the team. Reasonable cognitive load, reliable development environments and time to maintain the product make responsible autonomy possible. Heroics are weak evidence of a healthy Agile organisation.
6. Prefer rich, direct communication
In 2001, face-to-face conversation was identified as the most effective way to exchange information within a development team. The durable idea is high-bandwidth communication with fast clarification, especially when a problem is ambiguous.
For a colocated team that may be a conversation at a whiteboard. A distributed team may use a video call, pairing session or a concise written proposal followed by discussion. Remote work does not invalidate the principle, but it makes deliberate overlap, accessible decisions and good tools more important.
Direct conversation also needs a written trail where a decision will outlive the participants. The choice is not talk or documentation. Use conversation to resolve uncertainty, then record the decision, its important constraints and any consequence future maintainers need.
7. Judge progress by usable software
Plans, designs, tickets and status reports describe intent. Working software provides stronger evidence that the team has integrated its ideas into something executable. The seventh principle makes that the primary measure of progress.
Working should mean more than compiling on a developer machine. For the increment in question it includes relevant behaviour, integration, security, operability and a credible route to users. A feature hidden behind a flag may qualify when it is deliberately integrated and releasable; an untested branch with major integration work remaining does not.
This measure discourages reporting that converts incomplete inventory into comforting percentages. It is usually more honest to say that two thin capabilities work than that one large programme is 80 per cent complete.
8. Design work for a sustainable pace
Agility depends on a pace that sponsors, users and developers can maintain. Repeated overtime may increase output briefly, but fatigue, defects and deferred maintenance reduce the system’s future capacity to respond.
Sustainability is a delivery property as well as a wellbeing concern. Limit work in progress, keep operational load visible, reserve capacity for maintenance and do not plan every iteration as if no incident or discovery will occur. A team constantly rescuing brittle releases is not moving quickly in a useful sense.
Watch lead time, interruption load, defects, after-hours work and whether leave causes delivery to stop. Stable output produced without recurring heroics is more adaptable than occasional bursts followed by recovery.
9. Technical excellence creates room to change
The manifesto does not place speed in opposition to engineering quality. Continuous attention to design and technical excellence is what keeps later changes affordable. A system that can only move quickly by accumulating unsafe coupling is spending future agility.
The relevant practices depend on the product: clear boundaries, automated tests, continuous integration, observability, secure defaults, incremental refactoring and compatible database changes are common examples. None is valuable merely because it is labelled a best practice; it should reduce a real feedback delay or change risk.
This principle also rejects a separate hardening phase as the normal route to working software. Quality needs to travel with each increment. Otherwise frequent development produces frequent inventory rather than frequent delivery.
10. Remove work that does not need to exist
The simplicity principle describes maximising the work not done. It is more demanding than writing fewer lines of code. The team must question features, abstractions, hand-offs, reports and infrastructure that do not contribute enough value to justify their cost.
A small solution to the current problem is usually easier to verify and replace as understanding changes. This does not excuse careless shortcuts whose failure is already predictable. The simplest responsible design includes what is necessary for present behaviour, safety and operation without speculative machinery.
Backlog deletion is an Agile capability. If every requested idea remains queued indefinitely, prioritisation has only rearranged inventory. Removing low-value work creates capacity for learning and for the technical care that preserves future choices.
11. Let design emerge from an accountable team
The eleventh principle connects good architecture, requirements and design with self-organising teams. The people integrating these concerns should be able to shape the solution rather than receive disconnected decisions from specialist silos.
Emergent does not mean accidental. Teams still model important constraints, evaluate options and make architecture decisions. They do so iteratively, using evidence from implementation and operation, and keep the design open to correction instead of treating an early diagram as complete truth.
Self-organisation also needs a boundary. A team should know the outcome it owns, the standards it must meet and which decisions require coordination with others. Within that space it can adapt roles and working methods to the problem.
12. Inspect the way of working and make a change
The final principle closes the feedback loop on the team itself. At regular intervals, people examine how effectively they are working and adjust their behaviour. Reflection without an experiment is only discussion.
A useful retrospective starts from evidence: a delayed release, repeated interruption, an escaped defect, a smooth incident recovery or an unexpectedly successful collaboration. Choose a small change, name the result it should improve, give someone responsibility and revisit it.
Teams also need authority to fix causes beyond their immediate workflow. If the same organisational dependency appears every month and no one can change it, repeated retrospectives become theatre. Improvement should reach policies, platform constraints and ownership boundaries when those shape the outcome.
Use the principles as a connected system
The twelve principles reinforce one another. Frequent delivery creates feedback; close collaboration helps interpret it; simplicity and technical excellence make the next response cheaper; sustainable, trusted teams retain the capacity to act; reflection improves the whole loop.
Optimising one principle in isolation can undermine the rest. Release frequency without quality creates instability. Responsiveness without product direction creates churn. Team autonomy without access to customer or operational information creates local guesses.
Use the original principles as questions rather than a compliance checklist. Where does useful feedback arrive too late? Which work exists mainly to feed the process? What makes a change unsafe? Which decision is too far from the people with the evidence? The answers should guide the next improvement more than adopting another ceremony.
- Can users receive a small, useful change soon?
- How quickly does new evidence alter a decision?
- Is working, releasable software the clearest progress signal?
- Can product and engineering resolve ambiguity directly?
- Does the team have both autonomy and support?
- Can this pace continue without heroics?
- Does technical quality make the next change safer?
- What work, feature or process can be removed?
- What did the team learn, and what will it change next?