The full Manifesto values and principles in plain language, with worked examples of the inspect-and-adapt loop you can use before your first class.
Written in 2001 by seventeen practitioners frustrated with heavyweight, plan-driven processes. The full text is 68 words. Reading the original is worth more than any summary of it.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
That is, while there is value in the items on the right, we value the items on the left more.
That final sentence is the most important one. Agile does not say documentation, plans, or contracts are worthless. It says that when the two sides pull against each other, lean left. Plans are useful starting points. Working results are the measure of progress.
Each value names two genuinely good things and tells you which to favour under pressure. Here is what each one means in everyday terms, and when you will feel the tension between the two sides.
Good people talking to each other solve problems faster than any system designed to remove the need for conversation. A five-minute conversation between a designer and developer is worth more than a three-day ticket queue. The tool should serve the conversation, not replace it. When you feel yourself following a process that is making things slower, ask: what conversation would solve this faster?
A real, working thing teaches you more than any description of it. You learn whether a product is useful by watching real people try to use it — not by reviewing a specification that describes what it was supposed to do. The principle applies beyond software: a working prototype, a completed first chapter, a tested process — these teach more than documents about what they will eventually become. Progress is measured in working results, not completed paperwork.
Treat the customer as a partner working toward the same outcome, not as a counterparty across a contract. The contract-first instinct protects the original scope at the cost of the actual result. The collaboration-first instinct protects the result by keeping scope flexible. When a customer's needs change mid-project, the right question is "what matters most now?" not "is this in scope?"
A plan is a useful starting hypothesis, not a promise to reality. When you learn something new — about the user, the market, the problem — the plan should update, not be defended. This is not the same as having no plan. Agile teams plan constantly; they just treat plans as working documents rather than fixed contracts. The discipline is updating the plan early, based on evidence, rather than late, under pressure.
The principles sit behind the four values and give them practical shape. These are the original twelve, rewritten in direct language without jargon.
The highest priority is satisfying the customer through early and continuous delivery of valuable work. Not at the end — throughout.
Change is not a failure of planning. It is information. Agile processes are designed to turn late-arriving changes into competitive advantage rather than schedule disasters.
Short delivery cycles are the engine of learning. A two-week cycle gives the team 26 chances per year to course-correct. A six-month cycle gives them two.
The people who know what is needed and the people who can build it should be in daily contact. Handoffs and intermediaries slow everything down and introduce distortion.
Give people what they need and get out of the way. Micromanagement and motivated people are incompatible. The environment shapes the output more than the process does.
A direct conversation carries context, tone, and immediate clarification that no written document can replicate. Prefer conversation over documentation wherever possible.
Not documents signed. Not percentages complete. Not story points burned. Something real, working, that a person can use or see. Everything else is a proxy.
A team that sprints for three months and then collapses is not delivering more than a team that works steadily. Sustainable pace is not a concession to comfort — it is the strategy that produces consistent output over time.
Technical excellence is not a luxury to be addressed later. Shortcuts compound. Code that works today but cannot be changed tomorrow is a debt that slows every future Sprint. Quality built in from the start is faster than quality retrofitted at the end.
The most powerful question in Agile is "do we actually need this?" Features that are not built cannot have bugs, cannot confuse users, and cannot require maintenance. The discipline of saying no to work that does not serve the goal is as important as the discipline of doing the work well.
Teams that decide how to meet their goals outperform teams that are told how. The people closest to the work have the best information about how to do it. Trusting that judgment produces better outcomes than overriding it.
Build improvement into the rhythm of work. Every Sprint, the team asks: how did we work together, and how can we work better next time? The practice of honest reflection is what separates teams that improve from teams that plateau.
The inspect-and-adapt loop is not an Agile invention — it is a natural human learning pattern that Agile formalises. Every example below follows the same structure: make the real state visible, check it honestly, adjust.
This is a natural inspect-and-adapt loop. The "Sprint" is the cooking session. The "Sprint Review" is tasting and getting feedback. The "Retrospective" is deciding what to do differently next time. The key: you did not wait until the dish was served to find out if it needed salt. You checked early, when adjusting was cheap.
The original plan was useful — it got you started and set the direction. But it was not sacred. New information (the roadworks, the interesting detour) changed the plan in real time. Adapting made the outcome better. Rigidly following the original route would have made it worse.
Nobody improves at music by playing through the piece once at the end and hoping for the best. Improvement comes from short cycles of practice, honest inspection, and targeted adjustment. The feedback loop is the learning mechanism. The same is true for teams building software or any other complex work.
This is the reference table from Session 1, with additional rows. Use it to anchor the conceptual difference before class.
| Dimension | Traditional / Waterfall | Agile |
|---|---|---|
| Planning | Everything decided up front, in detail | Enough to start; refined as the team learns |
| Delivery | One big release at the end of the project | Small, working pieces delivered frequently |
| Change | Resisted — it breaks the plan and costs money | Expected and designed for — the plan absorbs it |
| Feedback | Late — after the build is complete | Early and continuous — built into every cycle |
| Progress measure | Documents completed, phases signed off | Working results in users' hands |
| Risk | Accumulates silently, surfaces at the end | Surfaced early in small, manageable doses |
| Customer involvement | At the start (requirements) and end (delivery) | Continuous — every Sprint Review |
| When each fits | Fixed, stable requirements; sequential work; regulatory compliance | Uncertain requirements; learnable problems; iterative delivery possible |
These misconceptions come up in almost every organisation that tries to adopt Agile. Addressing them before they take hold saves significant time.
Reality: Agile teams plan constantly — just in smaller, more frequent cycles rather than one large upfront exercise. The Sprint Goal is a plan. Backlog Refinement is planning. The release forecast is planning. Agile planning is more frequent and more responsive than traditional planning, not absent.
Reality: "Just enough, just in time" — not zero. Agile values working results over comprehensive documentation, which means you write what is genuinely useful and stop there. A team that writes no documentation and a team that writes only documentation are both doing it wrong. The test: does this document help someone do useful work? If yes, write it. If it exists only to prove the work was done, skip it.
Reality: The Manifesto was written by software practitioners, but the underlying values — short feedback loops, continuous delivery of value, welcoming change — apply to any work that involves uncertainty and learning. Marketing teams, design agencies, consulting firms, and operations teams use Agile practices effectively. The principles travel; specific ceremonies may need adapting.
Reality: Self-organising is not unmanaged. Agile teams have clear Sprint Goals, a Product Owner who owns priorities, a Definition of Done that enforces quality, and a Retrospective that holds the team accountable for improvement. The difference is that the team decides how to meet the goal — not whether to have one.
Reality: This almost always means: we adopted the ceremonies without the mindset. Standups became status meetings. Sprints became fixed-scope deadlines with a new name. Retrospectives produced no implemented actions. The practices without the thinking behind them produce overhead without benefit. The question is not "did we run Sprints?" but "did anything actually change based on what we learned?"