Study smarter with Fiveable
Get study guides, practice questions, and cheatsheets for all your subjects. Join 500,000+ students with a 96% pass rate.
The four values of the Agile Manifesto aren't just philosophical statements—they're the foundation that certification exams expect you to apply in real scenarios. You'll be tested on your ability to recognize when a team is violating these values, recommend corrections, and explain why Agile prioritizes certain approaches over traditional project management methods. Understanding these values deeply helps you answer questions about team dynamics, stakeholder engagement, iterative delivery, and change management.
Don't just memorize the four value statements. Know what problem each value solves, how it contrasts with traditional (waterfall) thinking, and when you'd invoke it to guide a struggling team. Exam questions often present scenarios where you must identify which value applies—so focus on the underlying principle, not just the words.
Agile fundamentally shifts project management from a process-driven discipline to a people-driven one. These two values recognize that software is built by humans for humans, and no amount of documentation or tooling can replace genuine collaboration.
Compare: Individuals and Interactions vs. Customer Collaboration—both prioritize human relationships over formal structures, but the first focuses internally (team dynamics) while the second focuses externally (stakeholder engagement). If an exam scenario involves communication breakdowns, identify whether the issue is within the team or between the team and customers.
Traditional project management often measures progress through artifacts—documents produced, milestones checked off, plans followed. Agile redirects focus to actual outcomes: working product and delivered value.
Compare: Working Software vs. Responding to Change—both reject traditional "success theater" (impressive documents, followed plans) in favor of real outcomes. Working Software measures what you've produced; Responding to Change governs how you adapt your approach. Exam questions may test whether you understand that a team can deliver working software while still failing to respond to change (e.g., building the wrong features because they refused to reprioritize).
A critical exam concept: the Manifesto states there is value in the items on the right (processes, documentation, contracts, plans)—but more value in the items on the left. This isn't binary rejection; it's prioritization.
Compare: All Four Values—exam questions often present scenarios where multiple values apply or conflict. A team that rigidly follows their sprint plan (violating Responding to Change) might justify it by saying they're delivering working software. Recognize that the values work together: working software built from outdated requirements still fails the customer collaboration and change response values.
| Concept | Key Values & Applications |
|---|---|
| Internal Team Dynamics | Individuals and Interactions—communication, trust, collaboration |
| External Stakeholder Engagement | Customer Collaboration—partnership, feedback, transparency |
| Measuring Progress | Working Software—functional product over artifacts |
| Handling Uncertainty | Responding to Change—flexibility, reprioritization, adaptation |
| Process vs. People | Individuals and Interactions—tools serve teams, not vice versa |
| Documentation Balance | Working Software—right-sized, just enough, just in time |
| Contract Flexibility | Customer Collaboration—trust replaces protective legal language |
| Planning Approach | Responding to Change—short iterations, continuous reprioritization |
A team has excellent Jira workflows and detailed process documentation, but struggles with miscommunication and blame culture. Which Agile value are they violating, and what would you recommend?
Compare "Customer Collaboration over Contract Negotiation" with "Responding to Change over Following a Plan"—what do they share, and how do their focuses differ?
A product owner insists on completing all originally planned features before release, even though user testing revealed three features are unnecessary. Which value(s) should guide your response?
Your organization requires compliance documentation for audit purposes. Does this violate "Working Software over Comprehensive Documentation"? Explain the balance the Manifesto actually advocates.
An FRQ asks you to evaluate a team that delivers working software every sprint but never incorporates customer feedback. Which values are they honoring, and which are they violating?