The Agile Manifesto and Principles

The Agile Manifesto is short — under a hundred words. The twelve principles fill another page. Together they fit on one screen, yet they shape every Agile framework that came after.

The Four Values

"We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.

That is, while there is value in the items on the right, we value the items on the left more."

The qualifying clause is the part most often misread. Documentation, plans, processes, and contracts still matter — they are simply not the goal. The goal is working software in the hands of customers.

Reading the Values

1. Individuals and interactions over processes and tools

A great team with a mediocre process beats a mediocre team with a great process. Buy software for the team, not the team for the software. When a process gets in the way of useful conversation, the process is wrong, not the conversation.

2. Working software over comprehensive documentation

The product is not the spec. A specification can be exhaustively correct and the resulting software still useless. Working increments — even rough — give the team and stakeholders something concrete to react to.

This does not mean "no documentation." Architecture decisions, runbooks, user-facing docs, regulatory artefacts — all valuable. The point is that documentation is in service of the software, not the other way around.

3. Customer collaboration over contract negotiation

Frozen contracts ("you said in March that the home page would have a carousel") punish learning. Real product work is closer to a partnership: the customer brings the problem and feedback; the team brings options and trade-offs; both adjust as they learn.

4. Responding to change over following a plan

The original plan was your best guess given what you knew at the time. New evidence is not a failure of planning — it is the point of planning. A team that cannot respond to change wastes the value of every lesson it learns.

The Twelve Principles

1. Customer satisfaction through early and continuous delivery. Ship something useful soon; keep shipping.
2. Welcome changing requirements, even late. Change is opportunity, not threat.
3. Deliver working software frequently. Weeks rather than months.
4. Business and developers work together daily. The Product Owner is in the team, not in another building.
5. Build projects around motivated individuals. Give them the environment and trust them.
6. Face-to-face conversation is the most efficient information channel. Today, "face-to-face" generously includes a synchronous video call when distributed.
7. Working software is the primary measure of progress. Not lines of code. Not story points. Not Jira ticket counts.
8. Sustainable pace. The team should be able to keep this up indefinitely. Heroic crunch is not Agile.
9. Continuous attention to technical excellence. Quality is not optional. Bad code makes change expensive.
10. Simplicity — the art of maximising the amount of work not done — is essential. Pick the smallest thing that works.
11. The best architectures, requirements, and designs emerge from self-organising teams. Top-down design rarely matches reality.
12. Regular reflection and adjustment. The team examines how it works and changes itself.

Plain-English Read

Stripped down: ship small, ship often, listen, change your mind willingly, write code worth changing, and don't burn out.

What People Get Wrong

• "Working software over documentation" → "no documentation." (No: enough docs to support working software.)
• "Responding to change" → "no commitments." (No: commitments at the right level — outcome and direction, not every detail.)
• "Self-organising teams" → "no managers." (No: managers exist; their job is to remove blockers and develop people, not to dictate task assignment.)
• "Simplicity" → "lazy." (No: choosing the smallest sufficient design takes more skill than choosing a big one.)

Principles in Action

If you only operationalise three principles, pick:

• Working software is the measure of progress. Stops vanity metrics.
• Sustainable pace. Stops burnout cycles that destroy teams.
• Reflect and adjust. Without retrospectives, the team cannot improve, and Agile becomes a static ritual.

Cert Mapping

With the values and principles in mind, the next module covers Scrum — the most widely used framework that tries to embody them.