002 - Agile Values
Goal
Develop a deep understanding of the four Agile Values beyond their original wording. Learn why they exist, how they influence everyday decision-making, the trade-offs they introduce, and how successful Agile teams balance both sides of each value instead of treating them as absolute rules.
Reading Time
| Level | Estimated Time |
|---|---|
| Quick Overview | 15 min |
| Complete Reading | 45–60 min |
| Including References | 60–75 min |
Mind Map
Agile Values
│
├── Why Values Matter
│ ├── Philosophy
│ ├── Decision Making
│ └── Trade-offs
│
├── Individuals & Interactions
│ ├── Collaboration
│ ├── Communication
│ ├── Teamwork
│ └── Leadership
│
├── Working Software
│ ├── Customer Value
│ ├── Incremental Delivery
│ ├── Feedback
│ └── Quality
│
├── Customer Collaboration
│ ├── Product Discovery
│ ├── Continuous Feedback
│ ├── Shared Ownership
│ └── Value Creation
│
├── Responding to Change
│ ├── Adaptability
│ ├── Continuous Learning
│ ├── Product Evolution
│ └── Risk Reduction
│
└── Applying the Values
├── Balancing Both Sides
├── Everyday Decisions
├── Common Pitfalls
└── Organizational Culture
Table of Contents
Prerequisites
- 000 - Foundations
- 001 - Agile Manifesto
Next Topics
- 003 - Agile Principles
- 004 - Lean Thinking
- 005 - Systems Thinking
1. Introduction
In the previous chapter, we explored the origins of the Agile Manifesto and introduced its four values.
Although these values are short and easy to memorize, their true meaning is often misunderstood.
Many organizations interpret the Agile Values as absolute rules:
- Documentation is bad.
- Planning is unnecessary.
- Processes should be ignored.
- Customers should decide everything.
None of these interpretations reflects what the Manifesto actually says.
The Agile Values are not rigid instructions.
They are principles that help teams make better decisions when faced with competing priorities.
Every software team must balance people with processes, software with documentation, collaboration with contracts, and planning with adaptability.
The Manifesto simply reminds us which side should receive greater emphasis when trade-offs become necessary.
Understanding these trade-offs is essential for applying Agile successfully.
Without this understanding, organizations often adopt Agile practices while continuing to think in traditional ways.
This chapter explores each Agile Value in depth, explaining not only what it says, but also why it exists, what it does not mean, and how it influences everyday product development decisions.
2. Understanding Agile Values
The four Agile Values are the foundation of Agile thinking.
Rather than prescribing specific practices, they provide guidance for making better decisions in environments characterized by uncertainty, complexity, and continuous learning.
Understanding them requires more than simply reading the four statements.
It requires understanding the philosophy behind them.
2.1 Values vs Rules
One of the biggest misconceptions about Agile is treating the Manifesto as a collection of rules.
It is not.
Rules tell people exactly what to do.
Values help people decide what they should do.
This distinction is fundamental.
Rules work well in predictable environments where every situation can be anticipated.
Software development is rarely predictable.
New information appears constantly.
Customer expectations evolve.
Technical constraints emerge unexpectedly.
No document can define the correct response for every possible situation.
Instead, Agile encourages teams to make decisions guided by shared values.
This creates consistency without removing professional judgement.
Think of the Agile Values as a compass rather than a map.
A map defines every step.
A compass simply helps you move in the right direction.
2.2 Why Trade-offs Matter
Every software team faces competing priorities.
Examples include:
- Deliver quickly or improve quality.
- Add more features or simplify the product.
- Write more documentation or spend more time coding.
- Follow the original roadmap or adapt to customer feedback.
None of these choices is inherently right or wrong.
Every decision involves trade-offs.
The Agile Values exist because software development is full of situations where multiple options appear reasonable.
Instead of eliminating these decisions, Agile helps teams make them consciously.
For example, choosing collaboration over rigid processes does not mean abandoning processes.
It means recognizing that when a process prevents effective collaboration, improving collaboration usually creates greater long-term value.
2.3 The Importance of Balance
Perhaps the most misunderstood sentence in the Agile Manifesto is:
"While there is value in the items on the right, we value the items on the left more."
This sentence changes everything.
The Manifesto never says:
- Documentation has no value.
- Processes have no value.
- Contracts have no value.
- Planning has no value.
In fact, all of these remain important.
Successful Agile teams understand that both sides are necessary.
The challenge is finding the appropriate balance.
Too much documentation slows delivery.
Too little documentation increases confusion.
Too much planning delays learning.
Too little planning creates chaos.
The Agile Values encourage thoughtful balance rather than absolute thinking.
3. Individuals and Interactions
📜 Original Value
Individuals and interactions over processes and tools.
This is the first—and arguably the most fundamental—Agile Value.
Everything else in Agile depends on people communicating effectively, collaborating openly, and continuously learning together.
Processes and tools support this goal.
They should never replace it.
3.1 Original Value
The original statement compares two important aspects of software development.
Individuals and interactions
over
Processes and tools
Notice that both sides are valuable.
Processes create consistency.
Tools improve productivity.
However, neither can compensate for poor communication, lack of trust, or ineffective teamwork.
Software is ultimately built by people.
The quality of their interactions often determines the quality of the product.
3.2 Why People Come First
Modern software development is fundamentally collaborative.
Building successful products requires contributions from:
- Product Managers
- Designers
- Developers
- Test Engineers
- DevOps Engineers
- Security Specialists
- Customers
- Business Stakeholders
No individual possesses all the knowledge required to build a successful product.
Instead, knowledge is distributed across the team.
Continuous communication allows that knowledge to emerge.
When communication breaks down, misunderstandings increase.
Features solve the wrong problems.
Architectural decisions become disconnected from business goals.
Customer feedback arrives too late.
Great teams succeed because they learn together.
Technology enables this collaboration.
People make it effective.
3.3 Processes Should Support People
Processes exist for a reason.
They improve consistency, reduce unnecessary work, and help organizations coordinate complex activities.
However, problems arise when teams begin optimizing for the process instead of the outcome.
Examples include:
- Completing every required document while ignoring customer feedback.
- Following Sprint ceremonies mechanically without meaningful collaboration.
- Measuring process compliance instead of customer outcomes.
- Prioritizing tool usage over productive conversations.
Healthy Agile organizations view processes as enabling mechanisms.
If a process consistently prevents collaboration or slows learning, the process should be improved—not blindly followed.
The same principle applies to tools.
Issue trackers, collaboration platforms, documentation systems, and AI assistants are valuable because they help people work together more effectively.
They are not goals in themselves.
3.4 Common Misconceptions
"Processes are unnecessary."
No.
Well-designed processes reduce confusion and improve consistency.
Agile encourages lightweight processes that support collaboration.
"Tools don't matter."
Modern software development depends heavily on excellent tooling.
Version control, CI/CD pipelines, automated testing, observability platforms, and collaboration tools significantly improve productivity.
The Agile Value simply reminds us that tools should enhance human collaboration rather than replace it.
"People can ignore agreed ways of working."
Agile values autonomy.
It also values accountability.
Successful teams establish shared working agreements and continuously improve them together.
3.5 Real-world Example
A development team adopts a sophisticated project management platform with automated workflows, dashboards, and detailed reporting.
Every task is carefully tracked.
Every process is documented.
Despite this investment, product delivery continues to slow.
After several Sprint Retrospectives, the team discovers the real problem.
Developers rarely speak directly with Product Managers.
Questions are submitted through tickets.
Design feedback waits days for approval.
Requirements are clarified only after implementation begins.
The tooling works perfectly.
The collaboration does not.
The team experiments with a simple change.
Developers and Product Managers begin holding short daily conversations whenever uncertainty arises.
Designers participate earlier in backlog refinement.
Engineers review features with stakeholders before implementation rather than after completion.
Within a few Sprints:
- Fewer misunderstandings occur.
- Less rework is required.
- Decisions are made faster.
- Customer feedback arrives earlier.
- Team satisfaction improves significantly.
The tools never changed.
The quality of the interactions did.
This is precisely what the first Agile Value encourages.
4. Working Software
📜 Original Value
Working software over comprehensive documentation.
Software exists to solve problems.
Customers do not buy documentation, diagrams, or project plans—they buy outcomes made possible by working software.
This value reminds us that the ultimate goal of software development is to deliver usable solutions that create value.
Documentation remains valuable, but only when it helps achieve that objective.
4.1 Original Value
The Agile Manifesto compares:
Working software
over
Comprehensive documentation
This comparison is often misunderstood.
The Manifesto does not reject documentation.
Instead, it argues that documentation should support software development rather than become the primary deliverable.
Software is valuable because it enables customers to accomplish something they could not do before.
Documentation is valuable because it helps people build, operate, and maintain that software.
The distinction is one of priority.
4.2 Delivering Customer Value
Customers measure value differently from development teams.
A team may celebrate completing:
- Requirements
- Architecture diagrams
- Design specifications
- Test plans
Customers cannot use any of these.
From their perspective, value begins only when working software solves a real problem.
This principle encourages teams to shorten the distance between an idea and customer value.
Rather than waiting months for a "complete" solution, Agile teams deliver useful increments that customers can evaluate immediately.
Each increment creates an opportunity to learn.
4.3 Measuring Progress
Traditional projects often measured progress through completed activities.
Examples include:
- Documentation finished
- Design approved
- Development phase completed
- Testing started
Agile introduces a different question:
Can the customer use it?
If the answer is no, progress remains uncertain.
Working software provides objective evidence that assumptions have become reality.
This makes software the most reliable indicator of genuine progress.
4.4 Common Misconceptions
"Documentation has no value."
Incorrect.
Architecture documentation, API references, onboarding guides, operational runbooks, and decision records remain extremely valuable.
The goal is useful documentation—not excessive documentation.
"We should release unfinished software."
No.
Working software should still meet the team's quality standards.
Agile encourages smaller valuable releases—not lower-quality releases.
"Progress only matters after production."
Not necessarily.
A working increment demonstrated to stakeholders during a Sprint Review also represents meaningful progress.
The key is that the software works.
4.5 Real-world Example
FitLife spent nearly three months documenting a new premium subscription experience.
The team produced user flows, technical specifications, UI designs, architecture diagrams, and implementation plans.
Everything appeared complete.
When development finally began, the Product Team discovered that customer priorities had already shifted.
Instead of requesting advanced subscription management, customers were asking for easier payment methods and family plans.
Much of the documentation had become outdated before implementation even started.
The team changed its approach.
Rather than documenting the entire subscription platform upfront, they delivered a small but functional subscription flow within a single iteration.
Customers immediately began using it.
Their feedback shaped every subsequent release.
Documentation still existed.
It simply evolved alongside the product instead of preceding it by several months.
5. Customer Collaboration
📜 Original Value
Customer collaboration over contract negotiation.
Successful products emerge through continuous collaboration between customers and product teams.
Requirements alone rarely capture everything customers truly need.
Learning together creates better products than relying exclusively on initial agreements.
5.1 Original Value
The Agile Manifesto compares:
Customer collaboration
over
Contract negotiation
Contracts define expectations.
Collaboration discovers solutions.
Both remain important.
However, software development is a learning process.
As understanding grows, collaboration becomes significantly more valuable than rigidly adhering to assumptions made months earlier.
5.2 Building Products Together
Customers are not simply recipients of completed software.
They are active participants in product development.
Continuous collaboration allows teams to understand:
- Customer problems.
- Business priorities.
- Market changes.
- Product opportunities.
Instead of attempting to define every requirement upfront, Agile teams validate assumptions continuously.
This reduces waste while increasing confidence that the product solves real problems.
5.3 Continuous Feedback
Feedback is one of Agile's greatest competitive advantages.
Every delivery creates an opportunity to learn.
Teams ask questions such as:
- Are customers using the feature?
- Does it solve the intended problem?
- Is the user experience intuitive?
- What should we improve next?
Without feedback, teams rely on assumptions.
With feedback, they rely on evidence.
5.4 Common Misconceptions
"The customer decides everything."
No.
Product Teams balance customer requests with technical feasibility, strategic direction, and business goals.
"Requirements no longer matter."
Requirements remain valuable.
The difference is that Agile expects them to evolve as new information becomes available.
"Customers should attend every meeting."
Collaboration does not require constant involvement.
It requires meaningful and regular communication at the right moments.
5.5 Real-world Example
FitLife planned to introduce social workout challenges.
Initial interviews suggested users wanted leaderboards.
After releasing a simple prototype, the Product Team observed something unexpected.
Most users ignored the rankings.
Instead, they repeatedly shared achievements with friends.
The original roadmap focused heavily on competition.
Customer behaviour revealed that motivation through social sharing mattered much more.
The roadmap changed.
Instead of expanding leaderboards, the team invested in friend invitations, achievements, and shared challenges.
This decision emerged through collaboration—not through assumptions made during initial planning.
6. Responding to Change
📜 Original Value
Responding to change over following a plan.
Planning remains important.
However, learning is even more valuable.
As new information becomes available, good plans evolve.
Rigid plans do not.
6.1 Adaptability over Predictability
Software development involves continuous discovery.
Customer needs evolve.
Competitors release new products.
Technology changes.
Business priorities shift.
The best teams recognize that change is inevitable rather than exceptional.
Instead of resisting change, they build systems capable of adapting quickly.
6.2 Continuous Planning
Agile does not eliminate planning.
It replaces one large planning event with continuous planning.
Plans become living artefacts.
Each Sprint, release, experiment, and customer conversation provides new information.
Teams use this information to refine priorities.
Planning therefore becomes an ongoing activity rather than a one-time prediction.
6.3 Continuous Learning
Every iteration generates knowledge.
Teams learn about:
- Customers.
- Technology.
- Product usage.
- Performance.
- Team effectiveness.
This learning becomes more valuable than preserving outdated plans.
Successful Agile organizations continuously replace assumptions with evidence.
6.4 Common Misconceptions
"Agile means no planning."
Incorrect.
Agile planning occurs continuously throughout the product lifecycle.
"Changing priorities indicates poor planning."
Not necessarily.
Changing priorities often reflect increased understanding.
Ignoring new information is usually more dangerous than adapting to it.
"Roadmaps become meaningless."
Roadmaps remain valuable.
They simply evolve as new evidence emerges.
6.5 Real-world Example
FitLife planned to spend an entire quarter building advanced nutrition tracking.
Development began exactly as planned.
Halfway through the quarter, analytics revealed a surprising trend.
Customers were abandoning the onboarding process before ever reaching nutrition features.
The biggest opportunity was no longer nutrition tracking.
It was improving onboarding.
Instead of protecting the original roadmap, Product and Engineering reviewed the new evidence together.
They paused nutrition development and focused on reducing onboarding friction.
Within two months:
- User activation increased.
- Customer retention improved.
- Subscription conversions grew.
The original roadmap was technically accurate.
The revised roadmap created significantly more customer value.
The team's success came not from following the plan perfectly, but from responding intelligently to new information.
7. Balancing the Four Values
After studying each Agile Value individually, it may be tempting to think that teams should always prioritize the left-hand side of each statement.
In reality, this would be just as problematic as always prioritizing the right-hand side.
The Agile Values are not independent rules.
They are complementary perspectives that help teams navigate complex decisions.
Every successful Agile team continuously balances:
- People and processes.
- Working software and documentation.
- Customer collaboration and formal agreements.
- Adaptability and planning.
The goal is not to maximize one value.
The goal is to make the best decision for the current context.
7.1 There Are No Winners
One of the biggest misunderstandings surrounding the Agile Manifesto is the belief that the items on the left always "win."
They do not.
Consider these examples:
| Situation | Better Choice |
|---|---|
| A new engineer joins the team. | More documentation may provide greater value. |
| A production incident occurs. | Well-defined processes become essential. |
| A regulated industry requires compliance. | Formal documentation and approvals are unavoidable. |
| A customer requests a critical change. | Collaboration becomes more valuable than rigid contracts. |
None of these decisions contradict Agile.
Instead, they demonstrate the importance of balancing competing needs.
The Manifesto provides guidance—not absolute rules.
7.2 Context Matters
Software development is highly contextual.
What works well for one team may be inappropriate for another.
Factors influencing Agile decisions include:
- Team size.
- Product maturity.
- Technical complexity.
- Regulatory requirements.
- Customer expectations.
- Organizational culture.
- Business risk.
For example:
A healthcare platform handling sensitive patient information will naturally require more documentation and governance than an early-stage startup validating a new product idea.
Both organizations can be Agile.
They simply apply the Agile Values differently according to their context.
Agility is not about doing the same thing everywhere.
It is about making appropriate decisions for the situation at hand.
7.3 Making Better Decisions
The Agile Values become most useful when teams face uncertainty.
Instead of asking:
"Which Agile rule applies here?"
Teams should ask questions such as:
- Are we optimizing for customer value?
- Does this process help or hinder collaboration?
- Are we learning from evidence or protecting old assumptions?
- Are we creating unnecessary work?
- Would more documentation genuinely help?
- Are we solving today's problem or yesterday's?
These questions encourage critical thinking rather than mechanical compliance.
Over time, Agile becomes less about following practices and more about developing judgement.
The most mature Agile teams are not those that follow Scrum perfectly.
They are the teams that consistently make better decisions.
8. Common Misconceptions
"The left side always replaces the right side."
No.
The Agile Manifesto explicitly states that both sides have value.
The left-hand items are simply given greater priority when trade-offs arise.
"Following Agile Values guarantees project success."
No.
The values improve decision-making.
They do not eliminate uncertainty, technical challenges, or market risks.
"Every Agile team should work the same way."
Agile encourages adaptation.
Different teams may legitimately choose different practices while sharing the same underlying values.
"Processes are anti-Agile."
Well-designed processes reduce friction, improve consistency, and enable collaboration.
Problems arise only when processes become more important than the people they are intended to support.
"Planning conflicts with Agile."
Planning is essential.
Agile simply treats plans as hypotheses that evolve through learning rather than fixed commitments that cannot change.
"The Agile Values are only relevant to software development."
Although created for software engineering, the values apply to any environment involving uncertainty, collaboration, and continuous learning.
This is why Agile principles have spread into product management, marketing, education, healthcare, finance, and many other industries.
9. 💼 In Practice
Case Study — FitLife Learns to Balance the Values
Several months into its Agile transformation, FitLife believed it finally understood the Agile Manifesto.
The engineering team proudly declared:
"We're Agile now."
Documentation was reduced dramatically.
Teams began changing priorities every Sprint.
Processes were simplified.
Meetings became informal.
Initially, everyone felt more productive.
However, new problems soon appeared.
New engineers struggled to understand the system because very little documentation existed.
Different teams interpreted requirements differently.
Roadmaps changed so frequently that stakeholders lost confidence in delivery forecasts.
Developers occasionally implemented different solutions to the same problem because working agreements had become unclear.
The Product Director realized something important.
The problem was not Agile.
The problem was imbalance.
The team had interpreted the Agile Values as replacements instead of priorities.
During a retrospective, they revisited the Manifesto.
One sentence stood out:
"While there is value in the items on the right, we value the items on the left more."
That sentence changed their perspective.
FitLife introduced lightweight architecture decision records.
Roadmaps became more stable while remaining flexible.
Documentation focused on knowledge that genuinely helped future teams.
Processes were simplified—but not eliminated.
Customer collaboration increased without abandoning strategic planning.
Over the following months, delivery became more predictable.
Quality improved.
New team members onboarded faster.
Stakeholder confidence returned.
FitLife discovered that Agile was never about choosing one side over the other.
It was about understanding when each side created the greatest value.
This lesson became one of the most important milestones in the company's Agile journey and established the mindset that would guide every future improvement throughout the rest of the Agile Bible.
10. 💡 Did You Know?
💡 Did You Know?
The Agile Manifesto Never Says "No Documentation"
One of the most common misconceptions about Agile is that documentation should be avoided.
The Manifesto never says this.
Its authors intentionally wrote:
"While there is value in the items on the right, we value the items on the left more."
Documentation remains valuable whenever it helps teams build, operate, maintain, or evolve software.
The real message is to avoid documentation that exists only because "the process requires it."
The Word "Agile" Appears Only a Few Times
The document is known worldwide as the Agile Manifesto, yet the word Agile appears only a handful of times.
The authors deliberately focused on values and principles rather than attempting to define another rigid methodology.
Scrum Is Not Agile
Many people use the terms interchangeably.
Scrum is one framework inspired by the Agile Manifesto.
Teams can follow Agile principles without using Scrum, and it is possible to follow Scrum mechanically without embracing Agile thinking.
Frameworks implement Agile.
They do not define it.
The Manifesto Is Remarkably Short
The entire Agile Manifesto consists of:
- Four Values
- Twelve Principles
Despite its brevity, it has influenced software engineering for more than two decades.
Its impact comes from encouraging better judgement rather than prescribing detailed rules.
Every Value Is a Balance
The Agile Manifesto never tells teams to eliminate:
- Processes
- Documentation
- Contracts
- Planning
Instead, it reminds us that when trade-offs become necessary, collaboration, customer value, adaptability, and people should receive greater emphasis.
11. 📝 Key Takeaways
- The four Agile Values are principles for decision-making, not rigid rules.
- Every value presents a trade-off rather than an absolute choice.
- Individuals and interactions enable effective collaboration and continuous learning.
- Working software is the most reliable indicator of meaningful progress.
- Customer collaboration replaces assumptions with evidence through continuous feedback.
- Responding to change recognizes that learning is more valuable than protecting outdated plans.
- Both sides of every Agile Value remain important—the challenge is knowing when to prioritize one over the other.
- Agile teams continuously balance people, processes, planning, documentation, collaboration, and adaptability.
- Applying the Agile Values successfully requires judgement, context, and continuous reflection.
- Agile maturity is measured less by following practices and more by consistently making better product decisions.
Remember
Agile is not about choosing the left-hand side.
It is about knowing when the left-hand side creates more value.
12. 📚 Further Reading
The Agile Values provide the philosophical foundation for every Agile framework and practice.
The following chapters expand these ideas into practical techniques for building successful products and teams.
Continue With
-
003 - Agile Principles
- Explore the twelve principles that transform the Agile Values into practical guidance for everyday product development.
-
004 - Lean Thinking
- Learn how Lean influenced Agile through concepts such as waste reduction, flow, and continuous improvement.
-
005 - Systems Thinking
- Understand why optimizing individual teams is rarely enough and how to improve entire product systems.
-
006 - Product Thinking
- Discover why successful organizations focus on outcomes instead of outputs.
Related Topics
Product Management
- Product Vision
- Product Strategy
- Product Discovery
- Outcome-Driven Development
- Product Metrics
Scrum
- Scrum Framework
- Scrum Team
- Scrum Events
- Scrum Artifacts
- Scrum Values
Agile Engineering
- Continuous Integration
- Continuous Delivery
- Test-Driven Development
- Refactoring
- Pair Programming
Leadership
- Servant Leadership
- Self-Managing Teams
- Coaching
- Facilitation
- Psychological Safety
Next Chapter
Continue with 003 - Agile Principles, where we explore the twelve principles of the Agile Manifesto in depth, examining how they influence product development, engineering practices, teamwork, and organizational decision-making.