Agile Manifesto and Principles

The Agile Manifesto and its 12 Principles form the philosophical foundation of Agile project management and are directly tested on the PMP exam. These values and principles guide how Agile teams prioritize work, respond to change, and deliver value. Understanding what each value emphasizes-and what it de-emphasizes-is critical for scenario-based questions where you must select the most Agile-aligned response.

Core Concepts

The Four Values of the Agile Manifesto

The Agile Manifesto contains four value statements that prioritize one element over another. The items on the left are valued more highly than those on the right, though both have value.

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

Each value statement does not reject the item on the right; it simply prioritizes the item on the left. For example, processes and tools matter, but people and how they communicate matter more. Documentation is useful, but a functioning product delivers more value. Contracts are necessary, but ongoing collaboration with the customer yields better outcomes. Plans provide direction, but flexibility to adapt to change creates better results.

When to Use This

• When an exam question asks you to choose between two valid actions and one aligns more closely with Agile values (e.g., holding a face-to-face conversation vs. updating a detailed process document)
• When a scenario presents a conflict between following a documented plan and adapting to new customer feedback-choose adaptation
• When deciding whether to invest time in creating comprehensive documentation or delivering a working increment-prioritize the working product
• When a stakeholder demands strict adherence to a fixed contract while the customer requests changes that add value-favor collaboration and flexibility

The 12 Agile Principles

The Agile Manifesto is supported by 12 principles that provide actionable guidance. These principles frequently appear in scenario questions where you must identify the most Agile-aligned behavior.

Principle 1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

This principle emphasizes delivering value incrementally and frequently rather than waiting until the end of a project. Teams should release working increments as soon as possible and continue delivering throughout the project lifecycle.

Principle 2: Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Change is not a disruption to be resisted but an opportunity to improve the product. Even if requirements change late in the project, Agile teams adapt because customer needs evolve and markets shift.

Principle 3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.

Short delivery cycles (iterations or sprints) allow teams to gather feedback quickly, reduce risk, and adjust direction based on real-world use. The shorter the cycle, the more responsive the team can be.

Principle 4: Business people and developers must work together daily throughout the project.

Agile removes barriers between the business side and the technical team. Daily collaboration ensures alignment, reduces misunderstandings, and enables quick decision-making.

Principle 5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Agile relies on self-organizing teams composed of motivated people. Leaders provide support and remove obstacles but do not micromanage. Trust is central to Agile team dynamics.

Principle 6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

Direct, synchronous communication reduces miscommunication and speeds up problem-solving. While remote tools are sometimes necessary, face-to-face interaction (including video calls) remains the gold standard.

Principle 7: Working software is the primary measure of progress.

Progress is not measured by completed documentation, tasks checked off, or time spent. The only true indicator of progress is a functioning product increment that delivers value.

Principle 8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Teams should avoid burnout by working at a sustainable pace. Overwork leads to errors, turnover, and decreased productivity. Agile values long-term health over short-term sprints of unsustainable effort.

Principle 9: Continuous attention to technical excellence and good design enhances agility.

High-quality code, sound architecture, and disciplined engineering practices make it easier to adapt to change. Technical debt slows teams down; technical excellence speeds them up.

Principle 10: Simplicity-the art of maximizing the amount of work not done-is essential.

Teams should focus on what is truly necessary and avoid over-engineering, unnecessary features, and gold-plating. Doing less work to achieve the same outcome is a sign of efficiency.

Principle 11: The best architectures, requirements, and designs emerge from self-organizing teams.

Agile teams are empowered to make decisions about how they work and what solutions they create. Command-and-control management is replaced by autonomy and collective ownership.

Principle 12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Continuous improvement is built into Agile through regular retrospectives. Teams do not wait for a post-project review; they inspect and adapt throughout the project.

When to Use This

• When a scenario asks how to handle a late-stage requirement change, apply Principle 2 and welcome it as an opportunity
• When choosing between a long planning phase and starting delivery quickly, apply Principle 3 and favor shorter cycles
• When a question involves measuring project progress, apply Principle 7 and select working increments over status reports or documentation
• When deciding how a team should communicate a complex issue, apply Principle 6 and choose face-to-face conversation over email or formal documentation
• When a team is working unsustainable hours to meet a deadline, apply Principle 8 and recommend adjusting scope or timeline to maintain a constant pace
• When a manager wants to assign tasks to team members, apply Principle 11 and allow the self-organizing team to decide how to distribute work
• When a team has completed a sprint and needs to improve, apply Principle 12 and hold a retrospective

Comparison of Agile Manifesto Values

Commonly Tested Scenarios / Pitfalls

1. Scenario: A customer requests a significant change to requirements late in the project. The team has already completed several sprints. What should the Agile team do?

Correct Approach: Welcome the change and work with the customer to integrate it into the backlog, re-prioritizing as needed. This aligns with Principle 2, which states that changing requirements should be welcomed even late in development.

Check first: Confirm that the change adds value to the customer and aligns with the product vision. Assess the impact on the current sprint and backlog.

Do NOT do first: Do not reject the change because it is late or because it was not in the original plan. Agile values responding to change over following a plan.

Why other options are wrong: Rejecting the change outright contradicts Agile values. Requiring formal change control processes or lengthy impact analyses delays value delivery and treats change as a problem rather than an opportunity.

2. Scenario: The project manager is asked how to measure the progress of an Agile project. Several options are presented: percent of tasks completed, number of documents produced, amount of working software delivered, or hours worked.

Correct Approach: Measure progress by the amount of working software delivered. This directly aligns with Principle 7, which states that working software is the primary measure of progress.

Check first: Identify whether the product increment is potentially shippable and delivers value to the customer.

Do NOT do first: Do not measure progress by completed tasks, documents, or hours worked. These are activity-based metrics, not outcome-based measures of value.

Why other options are wrong: Percent of tasks completed does not indicate whether the product works. Number of documents produced is an output, not a measure of customer value. Hours worked measures effort, not results.

3. Scenario: The team has been working long hours for three consecutive sprints to meet aggressive deadlines. Morale is low, and defects are increasing. What should the Agile leader do?

Correct Approach: Recommend adjusting the scope or timeline to allow the team to work at a sustainable pace. This aligns with Principle 8, which emphasizes maintaining a constant, sustainable pace indefinitely.

Check first: Assess whether the current pace is sustainable and whether quality is being compromised.

Do NOT do first: Do not push the team to continue at the current pace in the hope that they will "catch up" or that the deadline is more important than team health.

Why other options are wrong: Continuing unsustainable work leads to burnout, turnover, and technical debt. Adding more people mid-project often slows the team down due to onboarding overhead. Ignoring quality issues creates long-term problems.

4. Scenario: A stakeholder insists that the team create detailed design documentation before starting development. The team believes they can deliver a working increment more quickly by starting development and creating minimal documentation. What should the team do?

Correct Approach: Prioritize delivering a working increment and create only the documentation that is truly necessary. This aligns with the Agile value of working software over comprehensive documentation.

Check first: Determine whether the documentation is required for compliance, regulatory, or contractual reasons, or whether it is simply a preference.

Do NOT do first: Do not spend weeks creating detailed documentation before delivering anything functional. This delays feedback and value delivery.

Why other options are wrong: Creating comprehensive documentation upfront contradicts Agile values unless legally required. Delaying working software reduces opportunities for early feedback and adaptation.

5. Scenario: The team has completed a sprint and is preparing for the next one. The Scrum Master suggests holding a retrospective, but the Product Owner says it is unnecessary because the sprint went well. What should happen?

Correct Approach: Hold the retrospective regardless of how the sprint went. This aligns with Principle 12, which emphasizes regular reflection and continuous improvement.

Check first: Recognize that retrospectives are not just for fixing problems but for identifying improvements and reinforcing what went well.

Do NOT do first: Do not skip the retrospective because the sprint was successful. Continuous improvement applies even when things are going well.

Why other options are wrong: Skipping retrospectives breaks the inspect-and-adapt cycle and prevents the team from identifying opportunities for optimization. Retrospectives are a core Agile practice, not optional.

Practice Questions

Q1: A team is deciding how to communicate a complex technical issue to stakeholders. What is the most Agile-aligned approach?
(a) Send a detailed email with diagrams and explanations
(b) Schedule a face-to-face meeting or video call to discuss the issue
(c) Update the project wiki with the information
(d) Wait until the next status report to document the issue

Ans: (b)
Principle 6 states that face-to-face conversation is the most efficient and effective method of conveying information. Options (a), (c), and (d) rely on asynchronous, written communication, which is less effective for complex issues.

Q2: A customer requests a major feature change after the team has completed 80% of the project. How should the Agile team respond?
(a) Reject the change because the project is nearly complete
(b) Welcome the change and work with the customer to prioritize it in the backlog
(c) Require a formal change request and impact analysis before considering it
(d) Tell the customer to wait until the next project

Ans: (b)
Principle 2 emphasizes welcoming changing requirements, even late in development. Agile teams adapt to change for the customer's competitive advantage. Options (a), (c), and (d) treat change as a disruption rather than an opportunity.

Q3: How should an Agile team measure progress on a software development project?
(a) Number of hours worked by the team
(b) Percentage of tasks marked complete in the task management tool
(c) Amount of working software delivered to the customer
(d) Number of meetings held and documents produced

Ans: (c)
Principle 7 states that working software is the primary measure of progress. Hours worked, tasks completed, and documents produced are activity-based metrics, not measures of delivered value.

Q4: A team has been working 60-hour weeks for the past month to meet a deadline. Defects are increasing, and morale is low. What should the Agile leader recommend?
(a) Continue the pace to meet the deadline, then allow the team to rest afterward
(b) Add more team members to distribute the workload
(c) Adjust the scope or timeline to allow the team to work at a sustainable pace
(d) Implement stricter quality controls to reduce defects

Ans: (c)
Principle 8 promotes sustainable development and maintaining a constant pace indefinitely. Option (a) perpetuates burnout. Option (b) may slow the team due to onboarding overhead. Option (d) does not address the root cause of unsustainable work.

Q5: During sprint planning, the team debates whether to create detailed design documentation or start coding immediately. What is the most Agile-aligned decision?
(a) Create comprehensive documentation before coding to avoid mistakes
(b) Start coding and create minimal documentation as needed
(c) Assign half the team to documentation and half to coding
(d) Wait for the Product Owner to decide

Ans: (b)
The Agile Manifesto values working software over comprehensive documentation. Documentation should be minimal and created only when necessary. Option (a) delays value delivery. Option (c) splits the team's focus. Option (d) abdicates the team's responsibility to self-organize.

Q6: A project manager believes the team should follow the original project plan strictly, even though the customer has expressed new priorities. What Agile value is the project manager overlooking?
(a) Individuals and interactions over processes and tools
(b) Working software over comprehensive documentation
(c) Customer collaboration over contract negotiation
(d) Responding to change over following a plan

Ans: (d)
The Agile Manifesto values responding to change over following a plan. Sticking rigidly to the original plan ignores the customer's evolving needs. Options (a), (b), and (c) are relevant Agile values but do not directly address the tension between the plan and new priorities.

Quick Review

• The Agile Manifesto contains four values that prioritize individuals, working software, customer collaboration, and responding to change
• The 12 Agile Principles provide actionable guidance on delivering value, welcoming change, working sustainably, and improving continuously
• Principle 2: Welcome changing requirements, even late in development-treat change as an opportunity, not a disruption
• Principle 6: Face-to-face conversation is the most effective communication method-prefer direct, synchronous interaction over written documents
• Principle 7: Working software is the primary measure of progress-not tasks completed, documents produced, or hours worked
• Principle 8: Maintain a sustainable pace indefinitely-avoid burnout and long-term quality degradation
• Principle 11: Self-organizing teams produce the best solutions-empower teams to make decisions rather than assigning tasks top-down
• Principle 12: Reflect regularly and adjust behavior-hold retrospectives even when things are going well
• Agile values do not reject processes, documentation, contracts, or plans-they simply prioritize other elements more highly
• In exam scenarios, choose the response that aligns most closely with Agile values and principles, especially when trade-offs are involved