2.1 The Agile Manifesto (4 Values & 12 Principles)
Key Takeaways
- The Agile Manifesto establishes four foundational values prioritizing individuals, working increments, customer collaboration, and adaptability over rigid processes and contracts.
- Agile does not eliminate documentation or planning; it values working deliverables and responsiveness to change higher when trade-offs are necessary.
- The 12 Agile Principles provide operational guidance focusing on early continuous delivery, welcoming late changes, self-organizing teams, and a sustainable pace.
- PMI-ACP scenarios favor short feedback loops, customer collaboration, and empirical progress while still honoring documentation, accessibility, safety, and governance needs.
- Simplicity—defined as the art of maximizing the amount of work not done—is critical for preventing scope bloat and gold plating.
2.1 The Agile Manifesto (4 Values & 12 Principles)
The Agile Manifesto (officially the Manifesto for Agile Software Development) was created in February 2001 by 17 software pioneers at Snowbird, Utah. Frustrated by the high failure rates, administrative bloat, and rigid change-control mechanisms of traditional predictive (Waterfall) project management, these practitioners defined a fundamental mindset shift. On the PMI-ACP exam, the Manifesto serves as the ultimate benchmark: whenever faced with situational questions regarding team conflict, documentation requests, or changing requirements, your decision must align with Agile values and principles.
The 4 Core Values: Practical Exam Interpretation
The Manifesto explicitly states: "While there is value in the items on the right, we value the items on the left more." PMI-ACP exam questions often attempt to trick candidates into choosing traditional, plan-driven responses. Understanding the nuance of each core value is critical for selecting the correct answer.
| Left Side (Value Prioritized) | Right Side (Value Retained) | Exam Application & Situational Guidance |
|---|---|---|
| Individuals and interactions | Processes and tools | Prioritize direct communication, co-location, and team empowerment over software tools (e.g., Jira, Rally) or rigid procedural handoffs. |
| Working software | Comprehensive documentation | Progress is measured by functional, tested deliverables. Documentation should be fit for purpose: sufficient for users, operation, safety, regulation, and future learning without wasteful duplication. |
| Customer collaboration | Contract negotiation | Engage product owners and stakeholders in continuous feedback loops rather than treating contract terms as rigid barriers to changing needs. |
| Responding to change | Following a plan | Treat changes as competitive advantages. Baseline plans are initial hypotheses to be adapted based on empirical learning during iterations. |
Deep-Dive Analysis of the Core Values
1. Individuals and Interactions over Processes and Tools
Tools do not solve communication failures; humans do. When team members rely strictly on email, ticket updating, or automated workflows, misunderstandings multiply. When a process or tool creates friction, prefer the richest practical feedback channel and fix the underlying collaboration problem. Direct conversation may help, while distributed access, auditability, accessibility, or time zones may also require written and asynchronous communication.
2. Working Software over Comprehensive Documentation
Traditional projects produced massive Up-Front Requirements Documents (BRDs) and System Architecture Specs before writing code, leading to stale specifications and unvalidated assumptions. Agile prioritizes functional increments that stakeholders can inspect and validate.
PMI-ACP Exam Trap: Agile does not mean "no documentation." Compliance evidence, regulatory records, user manuals, and architectural guidance still need to meet their purpose. Produce and validate them with the increment instead of assuming either “no documentation” or “minimal documentation” is safe.
3. Customer Collaboration over Contract Negotiation
In predictive environments, scope is locked in contracts, creating an adversarial relationship between clients and delivery teams when requirements change. Agile breaks down this wall by embedding the Customer or Product Owner within the team. When needs change, collaborate on value and tradeoffs. In Scrum, the Product Owner orders the Product Backlog; in contractual or regulated work, the team also follows applicable change, notice, and approval obligations.
4. Responding to Change over Following a Plan
Predictive project management views scope change as a risk to be minimized or prevented through change control boards (CCBs). In Agile, change is welcomed as a source of market responsiveness and enhanced ROI. The plan is constantly updated through iteration planning, backlog refinement, and retrospectives.
The 12 Agile Principles: Operationalizing the Mindset
The 12 Principles provide actionable operational guidance to support the 4 core values. PMI-ACP situational questions frequently test your ability to map a real-world scenario to one of these principles.
1. Customer Satisfaction via Early and Continuous Delivery
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software (or deliverables). Delivering value in small increments mitigates financial and market risk early in the lifecycle.
2. Welcome Changing Requirements
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. If a market shift occurs during the final iteration, the Product Owner reprioritizes the backlog to maximize value.
3. Deliver Working Software Frequently
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Short delivery cycles enable rapid feedback, reduce queue length, and lower risks.
4. Daily Collaboration Between Business and Developers
Business people and developers must work together daily throughout the project. Co-locating or establishing daily communication channels prevents alignment drift and eliminates specification misunderstandings.
5. Build Projects Around Motivated Individuals
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Agile leaders act as servant leaders, removing impediments and empowering self-organization rather than command-and-control management.
6. Face-to-Face Conversation is Best
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. High-bandwidth communication minimizes misinterpretation compared to written documents or asynchronous emails.
7. Working Software as Primary Progress Metric
Working software (or usable deliverable value) is the primary measure of progress. Phase completion (e.g., "design 100% complete") is a vanity metric; only functional, tested deliverables reflect true progress.
8. Sustainable Development Pace
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Overtime burnout damages code quality, morale, and long-term velocity.
9. Continuous Attention to Technical Excellence
Continuous attention to technical excellence and good design enhances agility. Refactoring, automated testing, continuous integration, and clean code principles reduce technical debt, making future changes easier and cheaper to implement.
10. Simplicity: Maximizing Work Not Done
Simplicity—the art of maximizing the amount of work not done—is essential. Avoid unnecessary scope, over-engineering, and premature optimization while retaining the quality, safety, sustainability, and compliance work needed to deliver value responsibly.
11. Self-Organizing Teams
The best architectures, requirements, and designs emerge from self-organizing teams. Cross-functional teams closest to the technical details make better execution decisions than distant managers.
12. Regular Reflection and Tuning
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Retrospectives provide the formal structure for continuous empirical improvement (Kaizen).
PMI-ACP Exam Situational Traps & Decision Framework
When answering exam questions on the Agile Manifesto, apply these three core decision rules:
- Rule 1: Shorten the feedback loop. Prefer interactive conversation for ambiguity, while preserving documentation or escalation required by the risk, audience, or governance context.
- Rule 2: Evaluate change by value and constraints. In Scrum, bring a request to the Product Owner for Product Backlog management; also honor any safety, legal, regulatory, or contractual control that applies.
- Rule 3: Servant Leadership Over Command-and-Control. If a team is struggling with task allocation, do not assign tasks as a Project Manager. Facilitate a self-organizing discussion where the team estimates and pulls work based on capacity.
During Sprint 4 of a software project, a key client stakeholder requests a significant feature modification that was not defined in the initial scope agreement. How should the Agile Project Manager / Practitioner guide the team?
A software architect wants to build a complex, generalized database layer to support potential reporting features that might be required three years from now, even though current user stories only require basic CRUD functionality. Which Agile principle should be cited to redirect the architect?
To hit an aggressive release deadline set by executive management, a team has worked 70-hour weeks for three consecutive iterations. Quality metrics show a sharp rise in defects and team velocity has dropped. What is the root cause from an Agile perspective?