Professional Scrum Master I (PSM I) Certification Study
The Four Values of the Agile Manifesto
How to interpret the word "over," avoid common Agile misconceptions, and turn the Manifesto's four values into practical decision-making principles
Estimated reading time: 25 minutes
By João Ricardo Dutra••Complete article
Chapter objective
By the end of this chapter, you should be able to explain each value in depth, understand why the items on the right still matter, recognize common misinterpretations, and use the four values as practical decision-making lenses.
Introduction: Four Short Statements That Changed Software Development
does not ask us to choose between people and process, software and documentation, collaboration and contracts, or adaptation and planning. It asks us to remember which side should lead when the two come into tension.
In February 2001, seventeen experienced software practitioners met at Snowbird, Utah, after years of experimenting with approaches that were lighter, more adaptive, and more human-centered than the heavyweight processes common in many organizations. They came from different schools of thought - including ,,,, Adaptive Software Development, Feature-Driven Development, and pragmatic programming - but they shared a frustration: software projects were too often organized around documents, handoffs, approvals, contracts, and plans while the real goal - delivering useful software to real people - became secondary.
The result was the . Its wording was deliberately compact. Instead of prescribing a process, the authors expressed four value preferences. That decision is one reason the Manifesto has remained influential. The values do not tell a team which planning tool to use, how many meetings to schedule, what estimation technique to adopt, or which programming language to choose. They tell us what should receive greater attention when two useful things compete for time, authority, or organizational energy.
The four statements are now among the best-known ideas in modern software development: over ; over ; over ; and Responding to change over following a plan. Their apparent simplicity is also dangerous. Because they are easy to remember, they are easy to oversimplify. Organizations have used them to justify weak discipline, missing documentation, chaotic planning, poor contracts, and uncontrolled change. Those interpretations are not faithful to the Manifesto.
The final clarification in the Manifesto prevents this mistake: the authors explicitly state that the items on the right have value, but the items on the left are valued more. is therefore not a declaration of war against process, tools, documentation, contracts, or plans. It is an attempt to restore balance. The left-hand items are emphasized because they are closer to learning, communication, usable outcomes, customer value, and adaptation - the things that are easiest to lose when organizations become overly attached to mechanisms of control.
For a candidate, this chapter matters even though the is not the Scrum Guide. and are related but not identical. is a specific framework for complex product work; is broader and expresses values and principles shared across several approaches. Understanding the Manifesto helps explain why emphasizes , transparency, inspection, adaptation, usable Increments, collaboration with stakeholders, and responsiveness to learning.
The Four Values
over
over
over
Responding to change over following a plan
The sentence that protects the Manifesto from extremism
The authors did not say that the items on the right are worthless. They explicitly acknowledged their value. The Manifesto establishes a priority, not a prohibition.
What Does "Over" Really Mean?
The single most important word in the may be "over." Without understanding it, the four values collapse into false binaries. Readers start hearing "people instead of process," "software instead of documentation," "collaboration instead of contracts," and "change instead of plans." That is not what the Manifesto says.
In this context, "A over B" expresses relative preference. When there is tension between two valuable things, favor the item on the left when doing so better supports learning, value, communication, and adaptability. The right-hand item remains useful. It simply should not become the purpose of the work.
A build pipeline is a tool. It may be essential, but buying an expensive tool does not create effective collaboration. Architecture documentation may be valuable, but a perfect document does not compensate for software that cannot run. A contract may protect both supplier and customer, but a contract cannot anticipate every discovery that will emerge during a complex product initiative. A roadmap may create direction, but it becomes dangerous when people continue following it after evidence shows that the assumptions behind it are wrong.
The values therefore describe a hierarchy of attention. should enable people. Documentation should support and shared understanding. Contracts should create conditions for productive collaboration. Plans should guide action while remaining open to revision when reality changes.
A useful diagnostic question is: has the item on the right become a proxy for the result we actually want? A team may celebrate process compliance while users are unhappy. It may produce hundreds of pages of specifications while integration is failing. It may satisfy every clause in a contract while both parties know the product is losing relevance. It may deliver every item on a plan while the market opportunity has moved elsewhere. asks teams to notice that disconnect early.
Value 1 - over
Software is created through human judgment. Even when automation is extensive, people still decide what problem to solve, how to interpret ambiguity, which trade-offs to accept, how to design the system, what risks matter, and how to respond when assumptions fail. The first value recognizes that productive interaction between capable people is more important than the sophistication of the mechanisms surrounding them.
This does not mean processes are unnecessary. A useful process can reduce cognitive load, make expectations visible, support quality, create repeatability, and coordinate work across teams. Nor does it mean tools are unimportant. Version control, automated testing, , issue tracking, observability, infrastructure automation, and collaboration platforms can dramatically improve software delivery. The mistake is assuming that installing a tool or writing a process automatically solves a communication problem.
Imagine a team using an advanced work management platform with detailed workflows, required fields, automated status transitions, dashboards, and dependency maps. Every ticket is updated perfectly. Yet rarely talk directly with the . Testers receive work only after implementation. Architects communicate through approval comments. When a requirement is unclear, a Developer opens a ticket, waits two days, and continues with assumptions. The organization has excellent tooling but weak interaction.
The first value suggests that the highest-leverage improvement may not be another workflow rule. It may be a direct conversation. Rich interaction can expose misunderstandings before code is built, allow specialists to contribute earlier, and reduce the loss of information created by handoffs.
This value also challenges the idea that a process can replace judgment. In complex work, not every situation can be predicted and encoded in advance. A process can create boundaries and guardrails, but people must still inspect context and decide. therefore favors motivated professionals who can communicate directly, share knowledge quickly, and make decisions close to the work.
Common misinterpretation: means no process. That is false. Strong teams often have excellent engineering practices, explicit working agreements, quality standards, review rules, automation, and disciplined routines. The difference is that processes exist to help people create value; people do not exist merely to satisfy process.
Another misinterpretation is that tools do not matter. Tools matter enormously, but they should amplify good behavior. A weak collaboration culture with better software remains a weak collaboration culture. The best tool cannot create trust, psychological safety, shared purpose, or the willingness to have a difficult conversation.
Practical test for Value 1
If a problem can be solved faster and more accurately by the right people talking directly, but the organization forces the information through several tools, queues, or approval layers, the mechanism may have become more important than the interaction.
Value 2 - over
The second value redirects attention from descriptions of progress to evidence of progress. Before software exists in a usable state, many things can look convincing: requirement documents, architecture diagrams, project plans, design prototypes, test strategies, governance approvals, and status reports. They may all be useful, but none proves that the product actually works.
gives stakeholders something concrete to inspect. They can interact with it, discover misunderstandings, identify usability problems, observe performance, expose integration constraints, and decide whether the product is moving toward the desired outcome. In complex product development, this is a powerful form of knowledge creation. A running product reveals facts that a specification cannot.
The right-hand side - - still has value. Documentation can be essential for operating a system, transferring knowledge, complying with regulation, supporting security, explaining architecture, onboarding new team members, documenting APIs, recording decisions, or preserving information that would otherwise disappear. Some environments correctly require significant documentation because the cost of ambiguity is high.
The better question is not "documentation or no documentation?" It is "what documentation is valuable enough to create and maintain?" Documentation has creation cost and maintenance cost. A 200-page specification that becomes obsolete after three months may create more confusion than knowledge. A concise architecture decision record, accurate API contract, security model, operational runbook, or domain glossary may be far more useful because people actually use it.
Consider two teams. Team A has completed a detailed functional specification for a new checkout service but has not integrated payment, inventory, tax, or authentication. Team B has lighter documentation but has a small end-to-end checkout flow running in a test environment. Team A may appear further ahead according to document completion. Team B possesses stronger evidence because critical assumptions have already met reality.
Common misinterpretation: means we do not document. That is one of the most damaging myths in software development. Poor documentation can create dependence on individuals, increase operational risk, slow incident response, make onboarding painful, and weaken compliance. discourages documentation that becomes an end in itself, not documentation that creates lasting value.
Another misinterpretation is that means merely executable code. Software can run and still fail to deliver value. The deeper interpretation includes usefulness, quality, and the ability to generate meaningful feedback. A feature that technically works but cannot be safely released, operated, understood, or used by the target audience provides weak evidence of product progress.
Connection to
A that meets the is powerful because it creates transparency about what actually exists. It is evidence, not a promise about future completion.
Value 3 - over
The third value addresses one of the hardest realities of complex product development: at the beginning of an initiative, neither side knows everything. The supplier does not know every technical difficulty. The customer does not know every need that will emerge after interacting with the product. The market may change. Regulations may evolve. Competitors may introduce new capabilities. Real users may behave differently from what stakeholders predicted.
Contracts can be necessary. They define commercial expectations, responsibilities, liabilities, intellectual property, payment terms, scope boundaries, acceptance conditions, and risk allocation. In many regulated or multi-company environments, strong contracting is essential. The problem is not the existence of a contract. It is using the contract as a substitute for continued collaboration.
A purely contractual relationship encourages both sides to protect their position. Instead of asking what outcome creates the most value now, they may ask what the document said six months ago. A collaborative relationship treats the agreement as a framework for cooperation while keeping customer knowledge, technical knowledge, and evidence inside the decision loop.
Suppose a vendor is building a claims-processing platform for an insurer. The contract includes twelve major capabilities. After early releases, claims analysts reveal that one apparently minor workflow problem causes most of their daily delay. A contractual mindset may say that the improvement is outside scope and should wait for a formal change request. A collaborative mindset asks whether moving investment toward that problem would produce more value, and then works transparently through the commercial consequences.
The word customer also deserves care. The person paying for the product, the person using it, the person approving it, and the person affected by it may be different. Effective collaboration therefore requires access to relevant stakeholders and real user feedback, not just communication with one contractual representative.
Common misinterpretation: means contracts are unnecessary. False. The value says that successful product development cannot be reduced to contract compliance. A contract can define rights and responsibilities; it cannot replace ongoing discovery.
Another misinterpretation is that means doing everything the customer asks. Collaboration is not obedience. Customers contribute crucial knowledge about outcomes, context, constraints, and value. Product and engineering professionals contribute technical, design, operational, economic, and risk knowledge. Good collaboration combines these perspectives and sometimes requires challenging a requested solution.
Value 4 - Responding to Change over Following a Plan
The fourth value is often simplified to " welcomes change." That is true, but incomplete. The deeper idea is that plans are created using information available at a particular moment, while complex product development continuously produces new information. When evidence changes, responsible decision-making may require the plan to change as well.
Plans are valuable. They create direction, coordinate dependencies, support budgeting, expose assumptions, and help people reason about sequence and risk. teams plan frequently. The problem is not planning. The problem is treating the plan as more trustworthy than reality.
A plan made in January may assume a certain user behavior, technology cost, regulation, competitor position, or delivery capacity. By April, evidence may contradict several assumptions. Continuing to follow the original plan merely because it was approved can turn planning discipline into organizational denial.
Responding to change requires both flexibility and focus. does not mean changing direction every time someone has an idea. Constant random change destroys coherence. Good adaptation occurs when new evidence is important enough to justify changing a decision. Teams still need goals, priorities, and boundaries so that learning produces deliberate adaptation rather than chaos.
This distinction is especially important in . A creates short-term focus. Learning can cause the and to renegotiate scope during the , but changes should not endanger the . therefore combines adaptation with stability: a meaningful short-term objective remains, while the detailed plan can evolve as more is learned.
Consider a mobile banking team planning a feature for recurring transfers. Halfway through discovery and development, analytics show that most failed transfer attempts are caused by confusing recipient validation rather than by missing scheduling options. The team now has evidence that improving validation may create more value than completing every planned scheduling feature. thinking allows the evidence to influence future priorities.
Common misinterpretation: means no plan. In reality, adaptive work often requires more frequent planning. The plans are smaller, more current, and easier to revise. Another misconception is that all change is good. Change has cost - context switching, rework, architectural disruption, abandoned work, migration, training, and revalidation. does not glorify volatility. It supports economically justified adaptation.
The Four Values as a Learning System
The four values are usually taught separately, but their deepest meaning appears when they are viewed as a single system. improve the speed and quality of information exchange. produces concrete evidence. brings external knowledge and value judgments into the process. Responding to change converts that knowledge into adaptation.
Seen this way, the values describe a learning engine. People interact, create something usable, expose it to relevant stakeholders, learn from the result, and adjust direction. Processes, tools, documentation, contracts, and plans support that engine when used well. They become obstacles when they slow, filter, or distort learning.
This also explains why is not equivalent to speed. A team can deliver quickly and still be non- if it receives little user feedback, hides problems, follows orders without collaboration, or ships low-value work from a fixed backlog. Agility is the ability to learn and respond effectively, not merely to move quickly.
Likewise, is not simply flexibility. A team that changes priorities every day without coherent goals is flexible but not necessarily effective. The values assume discipline, technical competence, collaboration, feedback, and attention to valuable outcomes.
Practical Example - A Digital Lending Product
Imagine a bank developing a new digital personal-loan experience. The initial plan contains six months of work: a new application flow, automatic income verification, personalized offers, a document upload center, a repayment simulator, and a new credit decision engine. The organization already has a large project plan, a detailed specification, vendor contracts, and sophisticated tracking tools.
After the first few weeks, usability sessions reveal that many customers abandon the application before reaching the loan offer because they do not understand why certain personal information is requested. At the same time, compliance specialists raise a new interpretation of an identification requirement, and an external data provider announces a change to its API.
Applying the first value, product, engineering, compliance, design, and data specialists collaborate directly instead of sending the problem through a chain of tickets and approvals. The tools capture decisions, but interaction drives the learning.
Applying the second value, the team builds a small end-to-end version of the revised identity and consent flow instead of expanding the original requirements document for weeks. A working slice allows users and compliance specialists to inspect actual behavior, language, data capture, and audit evidence.
Applying the third value, the and relevant stakeholders review evidence together rather than debating whether the original specification technically covered the new experience. The central question becomes whether customers can understand the request, complete the process, and remain compliant.
Applying the fourth value, the team changes the near-term plan. Some personalization features are postponed so the identity flow and provider integration can be addressed first. This is not a failure to follow the plan. It is the plan becoming more accurate because reality supplied better information.
Notice what did not happen. The team did not abandon its tooling. It did not delete documentation. It did not ignore commercial agreements. It did not stop planning. The right-hand items remained present. The difference is that they served the work instead of controlling it. That is what the word "over" looks like in practice.
Common Misinterpretations to Eliminate
Misunderstanding the usually happens through exaggeration: a useful preference is converted into an absolute rule. The table below replaces common myths with more accurate interpretations.
Common Misinterpretations to Eliminate
Misinterpretation
More accurate interpretation
Individuals over processes means no process.
Use to support capable people, communication, and judgment. Do not let process compliance replace collaboration.
means no documentation.
Create documentation that supports operation, learning, compliance, maintenance, and shared understanding. Avoid documentation as a substitute for usable outcomes.
means no contracts.
Use contracts where needed, but maintain ongoing collaboration because complex needs cannot be fully captured at signing time.
Responding to change means no plans.
Plan continuously, then adapt plans when significant evidence changes what creates the most value.
means doing whatever the team wants.
Agility requires discipline, , transparency, accountability, feedback, and deliberate adaptation.
means faster delivery at any cost.
Speed matters only when it improves valuable learning and sustainable delivery.
A Decision Framework for Using the Four Values
The Manifesto becomes more useful when it moves from a poster on the wall to a decision framework. When a team faces tension, ask:
People and interaction: Is a workflow, approval chain, or tool delaying a conversation that the right people could resolve directly?
: Are we measuring progress through artifacts about the product instead of evidence from the product itself?
: Are we optimizing for contractual compliance while ignoring what customers or users are currently learning and needing?
Responding to change: Are we protecting a plan because it was approved even though new evidence shows another direction would create more value?
A mature interpretation
Do not automatically choose the left-hand item. Ask whether the item on the right is enabling or obstructing value and learning. maturity is not rejecting structure; it is designing structure that remains subordinate to outcomes.
Connection to and
The assessment is about , not about reciting the . Still, the four values provide useful conceptual background. is founded on and . It creates short feedback cycles through Sprints and formal opportunities for inspection and adaptation through its events. It defines a , and requires a .
If you understand the correctly, several ideas become more intuitive. The is not a process police officer; the accountability includes helping the team become more effective and . The protects the transparency of working results. The is not merely a contract-acceptance or demonstration meeting; it is an opportunity to inspect outcomes and determine future adaptations with stakeholders. creates a plan, but the is updated throughout the as more is learned.
At the same time, avoid a common exam mistake: do not answer a -specific question only from generic language. When the Scrum Guide establishes a specific rule, accountability, event purpose, or commitment, that definition matters. can help you understand the intent; the Scrum Guide remains the authoritative definition of .
Conclusion: Are Priorities for Better Decisions
The four values of the are powerful precisely because they are not a methodology. They do not prescribe a sequence of steps. Instead, they establish priorities for situations in which organizations can easily confuse the mechanism of work with the purpose of work.
remind us that complex software development depends on communication, trust, judgment, and collaboration. reminds us that usable outcomes reveal more than reports about outcomes. reminds us that value must be discovered and refined with people who understand the problem and its consequences. Responding to change reminds us that a plan is a hypothesis about the future, not the future itself.
The word "over" keeps all four values balanced. matter. Documentation matters. Contracts matter. Plans matter. The Manifesto's authors explicitly acknowledged their value. The insight is that these mechanisms should support human collaboration, usable outcomes, customer learning, and adaptation - not replace them.
In my view, this is why the Manifesto remains relevant decades after Snowbird. Technologies change quickly, but organizations still struggle with the same temptation: measuring what is easy to control instead of what is important to learn. A dashboard is easier to inspect than team trust. A document is easier to approve than product value. A contract is easier to defend than a difficult collaboration. A plan is easier to follow than an uncomfortable new fact. asks professionals to choose the harder but more useful path when evidence demands it.
As you continue your study, keep the four values as interpretive background and return to the Scrum Guide for the mechanics of . When you understand both the philosophy of adaptation and the structure that uses to enable it, events and artifacts stop looking like ceremony. They become parts of a disciplined system for learning in complexity.
Key Takeaways
"Over" means relative priority, not elimination.
The items on the right still have value and often remain essential.
People should be supported by , not dominated by them.
provides concrete evidence, while valuable documentation preserves knowledge and supports operation.
supplements contracts with continuous discovery and shared problem solving.
Responding to change requires frequent planning and evidence-based adaptation, not the absence of plans.
is not a license for chaos, weak engineering, missing documentation, or uncontrolled scope changes.
For , use as context, but use the Scrum Guide as the authoritative definition of .
Study note: The provides broader and principles. questions about should ultimately be interpreted according to the Scrum Guide and .org learning objectives.
