Agile Manifesto

The Agile Manifesto emerged from a February 2001 meeting of 17 software practitioners at Snowbird, Utah, who were associated with lightweight development methods such as Scrum, Extreme Programming, Crystal, and adaptive software development.³ The resulting text was deliberately brief: it defined a common outlook rather than a complete project-management system. Its stated purpose was to find better ways of developing software, so the manifesto should not be treated as a general philosophy of business, education, or personal productivity. The authors emphasized four preferences while preserving the value of the items on the right; the wording therefore establishes priorities, not absolute oppositions.¹ Different agile frameworks interpret those priorities through different roles, events, engineering practices, and planning styles.

The manifesto gives greater weight to people, working results, collaboration, and adaptability than to their formal substitutes. It values individuals and interactions over processes and tools, recognizing that communication and judgment often determine whether a process works in practice. It favors working software over comprehensive documentation, without declaring documentation useless; useful specifications, operational records, and compliance evidence can remain necessary. It prefers customer collaboration over contract negotiation, encouraging ongoing engagement rather than relying solely on an initial agreement. Finally, it chooses responding to change over following a plan, treating plans as provisional instruments rather than commitments that must survive changed evidence.¹ The repeated phrase “over” is central: the values are comparative, not licenses to abandon discipline, planning, or documentation.

The 12 principles translate the four values into a delivery model centered on frequent feedback and usable increments. They call for early and continuous delivery of valuable software, welcoming changing requirements, frequent releases, close cooperation between business and technical participants, and sustainable working practices.² They also emphasize technical excellence, simplicity, self-organizing teams, face-to-face communication, and regular reflection followed by adjustment. These principles explain why agile teams commonly use short development cycles, demonstrations, automated testing, backlog refinement, and retrospectives, although none of those techniques is mandated by the manifesto itself. Scrum, for example, defines its own accountabilities, events, and artifacts, while remaining one possible framework for expressing agile ideas.⁴ Agile development therefore combines a value system with context-specific engineering and organizational practices.

The manifesto’s lesser-known feature is its deliberately nonexclusive design: the signatories came from several competing or neighboring methods, yet the text avoided naming a single winner or prescribing a universal workflow.³ It also contains a qualification frequently lost in abbreviated quotations: the items on the right still have value. That clause distinguishes agile thinking from caricatures such as “no planning,” “no documentation,” or “no contracts.” The manifesto likewise says little about product discovery, organizational governance, portfolio funding, safety regulation, or large-scale coordination; later frameworks and practices had to address those concerns separately. Critics have argued that agile adoption can become superficial when ceremonies replace technical improvement or when flexibility is demanded mainly from workers. Research on agile methods consequently treats implementation as a sociotechnical change, not merely a set of meetings.

Agile software development

An umbrella term for iterative, incremental approaches to building software that emphasize feedback, collaboration, and adaptation.

Iteration

A bounded development cycle in which a team produces, evaluates, and improves a usable increment or other meaningful result.

Working software

Software that functions sufficiently for evaluation or use; in the manifesto, it is prioritized over exhaustive documentation, not necessarily substituted for it.

Self-organizing team

A team that determines how to accomplish its work rather than receiving every task and technical decision from outside authority.