Ir al contenido

The Agile Manifesto

De Scrum Manager BoK
Esta página es una versión traducida de la página El manifiesto ágil. La traducción está completa al 100 %.
⏱ 6 min  ·  📅 2026
The Agile Manifesto (Manifiesto Ágil in Spanish) is the declaration of four values and twelve principles that defines the conceptual foundation of agile methods. It was signed in February 2001 by seventeen software development professionals gathered in Snowbird (Utah), and was published as the founding reference of the agile movement at agilemanifesto.org.

Origin

In March 2001, 17 critics of process-based production models, convened by Kent Beck (who had published, a couple of years earlier, the book explaining the new Extreme Programming methodology), met in Salt Lake City to discuss software development.

At the meeting, the term "Agile Methods" was coined to define those that were emerging as an alternative to formal methodologies: CMM-SW, the precursor of CMMI, PMI, and SPICE (the initial project for ISO 15504), which they considered excessively "heavyweight" and rigid due to their normative nature and strong dependence on detailed planning prior to development.

The members summarized in four postulates what has come to be known as the "Agile Manifesto," which are the values on which these methods are based.

The four postulates

We value individuals and interactions over processes and tools


This is the most important value of the manifesto.

Processes support work and tools improve efficiency, but some tasks require talent and need people who bring it with the right attitude. Process-based production seeks to make the quality of the outcome a consequence of the know-how made explicit in the processes, rather than of the knowledge contributed by people. In agile development, processes are an aid, a support; the uncompromising defense of processes leads to the claim that, with them, extraordinary results can be achieved with mediocre people, which is not true when creativity and innovation are needed.

We value working software more than comprehensive documentation

Being able to anticipate how the final product will work by observing prototypes or parts already built provides stimulating feedback that generates ideas impossible to conceive when writing a requirements document at the start of the project.

The Agile Manifesto does not declare documentation useless, only unnecessary documentation. Documents record historical information and are mandatory in many legal or regulatory contexts, but their relevance should be lower than that of the final product. Communication through documents does not offer the richness achieved by direct communication or by interaction with product prototypes.

We value customer collaboration over contract negotiation

Agile practices are suited to products whose details are difficult to foresee at the outset and to contexts where unstable requirements are expected due to the pace of change in the business environment.

The goal of an agile project is not to monitor execution against plans, but to deliver the greatest possible value to the product. An ongoing relationship of involvement and collaboration with the customer is more appropriate than a contractual one that sets boundaries of responsibility.

We value responding to change over following a plan

When developing products with unstable requirements, for which change and rapid, continuous evolution are inherent factors, the ability to respond is far more valuable than the ability to follow plans and ensure they are met. The main values of agile management are anticipation and adaptation, as opposed to those of orthodox project management: planning and control.

The 12 principles

Following the four values, the Agile Manifesto sets out these twelve principles:

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9. Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity—the art of maximizing the amount of work not done—is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Common mistake

Treating the four values as absolute statements. The values of the Manifesto do not deny the usefulness of processes, documentation, contracts, or plans: they state that the other terms in each pair are more valuable. An agile team has documentation, has contracts, has plans; it simply does not turn them into the goal. Ignoring this nuance produces both "agilism without structure" (which abandons any process) and "facade agilism" (which performs all the rituals but does not adopt the values).

References

  • Beck, Kent. (2000). Extreme Programming Explained: Embrace Change. Addison-Wesley Professional.
  • Beck, Kent et al. (2001). Manifesto for Agile Software Development. agilemanifesto.org.

See also

Want to advance in agility? You can search for course and exam calls or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.