The Agile Manifesto and Its 12 Principles

Agile software development is an approach to building software through short feedback loops, close collaboration, and continuous adaptation. The Agile Manifesto expresses this approach through four values and twelve supporting principles.

Why Agile Emerged

Traditional development processes often tried to define the complete system, schedule, and budget before implementation began. This worked poorly when requirements changed, technical risks appeared late, or customers discovered what they really needed only after seeing working software.

Agile development addresses that uncertainty by treating software development as an iterative learning process. A team builds a small amount of useful software, gathers feedback, and adjusts its plans. Planning and design still matter, but they happen continuously instead of being completed only once at the beginning.

The Four Values

The Agile Manifesto states that, while there is value in the items on the right, agile practitioners value the items on the left more:

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

The word over is important. The Manifesto does not reject processes, tools, documentation, contracts, or plans. It says that they should support people in delivering useful software rather than becoming goals in themselves.

Individuals and Interactions

Software is created by people solving problems together. A capable team that communicates clearly can adapt when a process is incomplete or a tool fails. A perfect process cannot compensate for poor communication, missing trust, or unclear responsibility.

Processes and tools remain useful when they reduce friction. Daily coordination, code review, issue tracking, and automated builds should make collaboration easier rather than replace direct communication.

Working Software

Documents, diagrams, and plans can describe intent, but working software provides stronger evidence of progress. It exposes misunderstandings, integration problems, performance limits, and usability issues that may remain hidden in a specification.

Documentation is still valuable when it helps people use, maintain, or extend the system. Agile teams aim for documentation that serves a clear purpose instead of producing documents merely to satisfy a process.

Customer Collaboration

A contract defines responsibilities, but it cannot predict everything that will be learned during development. Regular collaboration lets customers and developers refine priorities as they gain new information.

This does not mean abandoning agreements. It means maintaining a working relationship in which decisions are based on current business needs rather than treating the original specification as untouchable.

Responding to Change

A plan records the best understanding available at a particular time. When requirements, markets, technology, or risks change, blindly following that plan can produce the wrong system efficiently.

Agile teams plan frequently and revise those plans using evidence. Adaptation is not an excuse for having no direction; it is a disciplined response to uncertainty.

The 12 Principles

The twelve principles explain how the four values influence day-to-day development.

1. Satisfy the Customer Through Early and Continuous Delivery

The highest priority is to satisfy the customer by delivering valuable software early and continuously. Early delivery allows customers to benefit sooner and gives the team real feedback before too much has been built on untested assumptions.

The practical question is not merely, “What can we finish?” but, “What is the smallest useful capability we can deliver and learn from?”

2. Welcome Changing Requirements

Changing requirements are accepted, even late in development, when they can improve the customer’s competitive advantage. Change should be evaluated rather than automatically resisted.

Welcoming change does not mean accepting every request without considering cost. It means designing the product, architecture, and process so that important changes remain possible and their tradeoffs can be discussed honestly.

3. Deliver Working Software Frequently

Teams should deliver working software in short intervals, preferring shorter timescales. Frequent delivery reduces the size of each change and shortens the time between an idea and its validation.

Automation is central to this principle. Reliable tests, builds, deployments, and monitoring make frequent releases safer and less expensive.

4. Business and Development Work Together Daily

Business stakeholders and developers should collaborate throughout the project. Frequent communication prevents developers from implementing outdated assumptions and helps business participants understand technical constraints.

The goal is fast access to decisions and context. The exact form may be a product owner, direct stakeholder conversations, shared planning sessions, or another arrangement suited to the team.

5. Build Around Motivated Individuals

Projects should be built around motivated people who receive the environment, support, and trust needed to complete the work. Knowledge work is difficult to manage through detailed command-and-control instructions.

Trust is paired with responsibility. Teams need clear goals, the authority to make local decisions, and feedback that shows whether those decisions produce the desired results.

6. Prefer Direct Communication

The Manifesto describes face-to-face conversation as the most effective way to communicate within a development team. Its underlying concern is communication with high bandwidth and rapid feedback.

For distributed teams, video calls, pairing sessions, shared diagrams, and concise written decisions can serve the same purpose. Important decisions should still be recorded when people will need them later.

7. Measure Progress by Working Software

Working software is the primary measure of progress. Tasks completed, hours spent, and documents produced may show activity, but they do not prove that the product can deliver value.

A feature is meaningful progress when it is integrated, tested, and usable under an agreed definition of done. This principle discourages reporting partially completed work as if it were finished.

8. Maintain a Sustainable Pace

Agile processes promote sustainable development. Sponsors, developers, and users should be able to maintain a steady pace indefinitely.

Repeated overtime hides capacity problems and usually creates defects, fatigue, and staff turnover. A sustainable pace supports predictable delivery and preserves the team’s ability to respond thoughtfully to change.

9. Pursue Technical Excellence and Good Design

Continuous attention to technical excellence and good design improves agility. Automated testing, refactoring, clear interfaces, continuous integration, and careful design keep the cost of future changes manageable.

Agility is not the absence of architecture. It favors enough design for the current problem while continually improving the design as the team learns more.

10. Maximize the Work Not Done

Simplicity means maximizing the amount of work not done. Every feature has implementation, testing, documentation, operational, and maintenance costs. Avoiding unnecessary work leaves more capacity for valuable outcomes.

This principle encourages teams to challenge speculative features, premature abstractions, excessive documentation, and process steps that do not improve the product.

11. Let Teams Self-Organize

The best architectures, requirements, and designs emerge from self-organizing teams. The people closest to the work often have the information needed to coordinate tasks and make technical decisions.

Self-organization does not mean a lack of leadership or constraints. Leadership establishes goals, boundaries, and support; the team determines how to accomplish the work within them.

12. Reflect and Adjust Regularly

At regular intervals, the team reflects on how to become more effective and then changes its behavior. Retrospectives turn experience into concrete process improvements.

Reflection matters only when it leads to action. A useful retrospective identifies a small improvement, assigns responsibility, and checks later whether the change helped.

Connecting Values and Principles

The four values describe priorities, while the twelve principles describe habits that reinforce those priorities:

The relationships are not exclusive. For example, technical excellence supports both working software and the ability to respond to change.

Agile Is Not a Particular Framework

Scrum, Extreme Programming, Kanban, and other methods can help teams apply agile ideas, but none is identical to agility itself. A team may follow every ceremony in a framework while receiving little customer feedback and releasing software rarely. Such a team follows a process without embracing the Manifesto’s priorities.

Conversely, a team can work in an agile way without using a named framework if it delivers incrementally, collaborates closely, maintains technical quality, and adapts based on feedback.

Practical Questions for a Team

The Manifesto can be used as a set of questions rather than a checklist:

• How quickly can customers evaluate a working increment?
• What evidence shows that the latest work creates value?
• Can an important requirement change without destabilizing the entire system?
• Do business and technical participants resolve questions quickly?
• Does the team have enough autonomy to improve its way of working?
• Are tests, design, and deployment practices making future changes easier?
• What work can be removed without reducing the desired outcome?
• Is the current pace sustainable?
• What did the team learn, and what will it change as a result?

Agile development is ultimately a feedback-oriented discipline. Its values guide priorities, and its principles create conditions in which teams can learn early, deliver useful software, and adapt responsibly.

References

1. Kent Beck et al. Manifesto for Agile Software Development. 2001. https://agilemanifesto.org/
2. Kent Beck et al. Principles behind the Agile Manifesto. 2001. https://agilemanifesto.org/principles.html
3. Robert C. Martin. Agile Software Development: Principles, Patterns, and Practices. Pearson, 2002.