Opening the book…
Manifesto of the software anarchists
In 2001, a group of software development leaders met in Snowbird, Utah, to discuss better ways of developing software. At the time, many organizations were frustrated with heavy, document-driven methods. Projects often spent months or years creating detailed specifications before customers saw anything usable. By the time the product was delivered, market needs had changed, users were dissatisfied, and teams were exhausted.
The group did not create one single methodology. Instead, they identified common values shared by several lightweight approaches. The result was the Agile Manifesto.
The Agile Manifesto is short, but its impact is enormous. It provides the philosophical foundation for modern adaptive delivery. Most Agile frameworks, including Scrum, Extreme Programming, Lean-inspired Agile, and Kanban-based delivery, can be understood as practical ways of applying the Manifesto.
The Agile Manifesto is not anti-process, anti-documentation, anti-contract, or anti-planning. This is one of the most important misunderstandings to avoid. The Manifesto does not say the items on the right have no value. It says the items on the left have more value.
In other words, Agile does not say, “Never document.” It says, “Do not let documentation become more important than delivering a working solution.” Agile does not say, “Never plan.” It says, “Do not become so attached to a plan that you ignore new evidence.”
The right-side items have value, but the left-side items create agility.
- Individuals and interactions over processes and tools.
- Working software over comprehensive documentation.
- Customer collaboration over contract negotiation.
- Responding to change over following a plan.
The Agile Manifesto contains four value statements:
Individuals and interactions over processes and tools.
This means people matter more than procedures. A process is useful only when it helps people collaborate and deliver value. A tool is useful only when it makes work more transparent or efficient. Agile teams do not blindly worship tools, templates, workflows, or governance systems.
For example, a team may use Jira, Azure DevOps, Trello, or sticky notes on a wall. The specific tool is less important than whether the team is communicating clearly, making work visible, and solving problems together.
In PMI-ACP questions, this value often appears when there is a conflict between following a formal process and having a direct conversation. The Agile answer usually favors collaboration, facilitation, and communication over bureaucracy.
Working software over comprehensive documentation.
Originally, the Manifesto referred to working software because Agile emerged from software development. In broader Agile project management, we can think of this as a working product, working increment, usable deliverable, or validated outcome.
The point is that real progress is demonstrated by something useful, not by documents alone. Requirements documents, design documents, and status reports may support the work, but they are not the same as delivered value.
For PMI-ACP, remember that Agile teams measure progress primarily through delivered value. A beautiful plan, a polished slide deck, or a 200-page specification does not prove that the customer has received anything useful.
Customer collaboration over contract negotiation.
Agile recognizes that customers often discover what they truly need only after they see, test, and use early versions of the product. Therefore, Agile teams work closely with customers and stakeholders throughout delivery.
This does not mean contracts are ignored. Contracts matter, especially in vendor relationships. However, Agile prefers contracts and agreements that support collaboration instead of creating adversarial relationships.
A predictive mindset may say, “The contract says this, so we will deliver this even if the customer now knows it is not valuable.” An Agile mindset says, “Let us collaborate within the boundaries of the agreement to maximize value.”
Responding to change over following a plan.
This is one of the most frequently tested Agile ideas. Agile teams plan, but they also recognize that plans are based on assumptions. As the team learns more, the plan must be updated.
The Agile mindset treats change as information. A change request may reveal a new customer need, a market shift, a risk, a technical discovery, or a misunderstanding. The team should inspect the change, assess its value, and adapt the backlog appropriately.
This does not mean every change automatically enters the current iteration. Agile teams still protect focus. The Product Owner or equivalent role helps prioritize changes based on value, risk, urgency, and capacity.
This page titled 1.2.1: Agile Manifesto and Agile Principles was last modified on Sun, 07 Jun 2026 22:35:06 GMT and is shared under a CC BY 4.0 license and was authored, remixed, and/or curated by Guharaman Janakiraman.
The book could not be loaded just now.