Beck Extreme Programming Guide

A practical guide to Kent Beck’s software development principles, extracted from Extreme Programming Explained: Embrace Change (2nd Edition, 2004).

Twenty years after its publication, XP remains relevant because it addresses the fundamental challenge: software is built by people, for people. The technical practices (TDD, CI, pair programming) get the attention, but Beck’s deeper insight is that sustainable software development requires attending to human needs—communication, trust, respect—alongside technical excellence.

This guide serves two purposes:

XP philosophy — Values, principles, and the “why” behind practices
XP practices — Concrete techniques for teams to adopt

XP is about social change, not just technical practices.

“XP is about social change. It is about letting go of habits and patterns that were adaptive in the past, but now get in the way of us doing our best work.”

Beck’s central thesis: reconcile humanity and productivity. The more humanely you treat yourself and others, the more productive everyone becomes.

Outstanding software requires both:

Good relationships — trust, communication, respect
Good technique — TDD, CI, refactoring

The promise of XP:

Sustainable pace (no death marches)
Fewer defects
Continuous improvement
Software that actually solves problems

“XP is about being open about what we are capable of doing and then doing it. And, allowing and expecting others to do the same.”

2. The Driving Metaphor: Learning to Drive

Don’t point the car at your destination and hope. Drive by making continuous small corrections.

“Everything in software changes. The requirements change. The design changes. The business changes. The technology changes. The team changes. The team members change. The problem isn’t change, because change is going to happen; the problem, rather, is our inability to cope with change.”

Software development = staying in the lane through constant adjustment.

Key insight: Change is not the problem; inability to adapt is.

The driver:

Pays attention
Makes small corrections
Doesn’t oversteer
Accepts that the road has curves

XP teams do the same with code.

3. Values, Principles, and Practices

The XP framework has three layers:

Layer	Purpose	Example
Values	What we care about	Communication, Simplicity
Principles	Bridge values to action	Humanity, Economics
Practices	What we do	Pair Programming, TDD

        Values
         /|\
          |    (principles translate)
          v
      Principles
         /|\
          |    (practices implement)
          v
       Practices

Key insight: Practices without values become empty rituals. Values without practices stay abstract ideals.

You can’t just adopt practices mechanically. Understanding why they work lets you adapt them to your context and invent new ones when needed.

4. The Five Values

Value	Description	Counter-pattern
Communication	Face-to-face, real-time, whole-team	Documentation as substitute for conversation
Simplicity	“What is the simplest thing that could possibly work?”	Over-engineering for hypothetical futures
Feedback	Concrete, frequent, from system and customers	Long cycles between feedback opportunities
Courage	Tell the truth, act on what you see	Covering up mistakes, avoiding hard conversations
Respect	Everyone’s contribution matters	Hero culture, blame, dismissing ideas

Communication

Communication isn’t just information transfer—it’s creating shared understanding and team identity.

“Communication is important for creating a sense of team and effective cooperation.”

Problems in software projects often come from someone not talking to someone else. Practices like pair programming, daily standups, and sitting together exist to maximize communication bandwidth.

Simplicity

Simplicity is the hardest value intellectually.

“To make a system simple enough to gracefully solve only today’s problem is hard work.”

Simplicity is context-dependent: a parser generator is “simple” if your team knows parser generators.

Taking it too far — Simplicity: “Simplest thing that could work” doesn’t mean “quick hack.” It means the clearest, most direct solution—which often requires MORE thought, not less.

Feedback

Feedback makes the other values concrete:

Is the system working? → Run the tests
Is the customer happy? → Deploy and ask
Is the team improving? → Retrospect

“Feedback is a critical part of communication… Feedback also contributes to simplicity.”

Feedback requires courage (to hear it) and communication (to act on it).

Courage

“Courage is effective action in the face of fear.”

Courage means:

Telling the truth about progress
Throwing away code that doesn’t work
Raising problems early
Accepting responsibility

Courage alone is dangerous—it needs other values to guide action. Doing something without regard for consequences isn’t courage; it’s recklessness.

Respect

“If members of a team don’t care about each other and what they are doing, XP won’t work.”

Respect underlies all other values. Without it:

Communication becomes defensive
Simplicity becomes “my way”
Feedback becomes criticism
Courage becomes aggression

Others

The five values aren’t the only possible values for effective software development—they’re the driving values of XP.

“Your organization, your team, and you yourself may choose other values. What is most important is aligning team behavior to team values.”

Other important values teams might hold:

Safety — psychological and physical
Security — protecting assets and data
Predictability — consistent delivery
Quality-of-life — sustainable happiness

Holding these values would shape practices differently than XP’s five do. The key is alignment: minimize waste from maintaining multiple conflicting value sets.

5. Key Principles

Principles bridge values to practices.

Humanity

Software is built by humans with human needs:

Security — freedom from fear
Accomplishment — contributing to something meaningful
Belonging — identification with a group
Growth — opportunity to expand skills
Intimacy — close relationships

“What do people need to be good developers? Basic safety, accomplishment, belonging, growth, intimacy.”

Ignoring humanity leads to burnout and turnover.

Economics

Software development must make business sense. Time value of money: a dollar today is worth more than a dollar tomorrow.

This justifies:

Incremental delivery (value sooner)
Deferring decisions (cheaper later)
Stopping when you have enough

Mutual Benefit

Every activity should benefit all parties NOW, not trade off present for future.

Writing tests benefits you now (design feedback) AND later (regression safety). Documentation that only helps future maintainers violates this principle—find a way that helps everyone.

Baby Steps

Small changes, frequently integrated.

“What if there was a way to move forward with a tiny step? What if you could make things a little better without making things a lot worse?”

What’s the least you could do that’s recognizably in the right direction?

Other Principles

Principle	Meaning
Self-Similarity	Apply patterns at all scales (stories in iterations in releases)
Improvement	“Perfect” is a verb, not an adjective
Diversity	Multiple perspectives solve problems better
Reflection	How and why, not just what
Flow	Continuous delivery of value, not batched
Opportunity	Problems are opportunities to learn
Redundancy	Critical problems need redundant solutions
Failure	Not trying is worse than failing
Quality	Quality is not negotiable; scope is
Accepted Responsibility	Responsibility cannot be assigned, only accepted

6. Primary Practices

These can be adopted immediately, without prerequisites:

Practice	Description	Key Insight
Sit Together	Open space for whole team	Communication happens with all senses
Whole Team	Cross-functional, all skills present	“We belong, we’re in this together”
Informative Workspace	Status visible at a glance	Story wall, visible charts

Informative Workspace

Make your workspace about your work.

“An interested observer should be able to walk into the team space and get a general idea of how the project is going in fifteen seconds.”

Key elements:

Story wall — Cards sorted spatially (To Do, In Progress, Done)
Big visible charts — Track issues requiring steady progress
Human needs — Water, snacks, cleanliness, some privacy

If the “Done” area isn’t collecting cards, something’s wrong with planning, estimation, or execution.

When an issue is resolved or a chart stops getting updated, take it down. Use space for important, active information only.

Energized Work

Sustainable pace (~40 hours)

Tired programmers remove value

Energized Work

Work only as many hours as you can be productive and sustain.

“Burning yourself out unproductively today and spoiling the next two days’ work isn’t good for you or the team.”

The myth of long hours:

Where’s the evidence that 80-hour weeks produce more value than 40-hour weeks?
Software development is a game of insight
Insight comes to the prepared, rested, relaxed mind

Long hours often signal loss of control:

“I can’t control how the whole project is going; I can’t control whether the product sells; but I can always stay later.”

With enough caffeine and sugar, you can keep typing long past the point where you’re removing value. When you’re tired, it’s hard to recognize you’re making things worse.

When you’re sick: Stay home. Coming in sick doesn’t show commitment—it slows your recovery and risks the team.

Practice	Description	Key Insight
Pair Programming	Two at one machine	Dialog, not dictation
Stories	Customer-visible functionality units	Short names, index cards, early estimates

Stories

Stories are the unit of planning in XP. They represent customer-visible functionality.

“Software development has been steered wrong by the word ‘requirement’, defined in the dictionary as ‘something mandatory or obligatory.’ The word carries a connotation of absolutism and permanence, inhibitors to embracing change.”

Story characteristics:

Short name — “User login”, “Export report”
Brief description — Prose or graphical, fits on an index card
Early estimate — Rough cost before detailed design
Customer-written — Business language, not technical

Why index cards work:

Physical → visible on wall
Spatial sorting → conveys status at a glance
Low-tech → anyone can write one
Disposable → easy to tear up and rewrite

“Every attempt I’ve seen to computerize stories has failed to provide a fraction of the value of having real cards on a real wall.”

Weekly and Quarterly Cycles

Weekly Cycle:

Meeting at the beginning of every week
Review progress, pick stories, break into tasks
Goal: deployable software by Friday

“The team’s job—programmers, testers, and customers together—is to write the tests and then get them to run in five days.”

Quarterly Cycle:

Reflect on team, project, alignment with larger goals
Identify bottlenecks (especially those outside team control)
Plan themes for the quarter

Planning is “necessary waste”—it doesn’t create value by itself. Work to reduce the percentage of time spent planning.

Practice	Description	Key Insight
Slack	Include droppable tasks	Buffer against uncertainty
Ten-Minute Build	Full build + tests in 10 min	Faster → more frequent → better feedback
Continuous Integration	Integrate after hours, not days	Smaller batches = cheaper integration
Test-First Programming	Write test before code	Scope control, design feedback, rhythm
Incremental Design	Design every day	“The most effective time to design is in the light of experience”

War Story — Sit Together:

“I was called to consult at a floundering project… The senior people had corner offices, one in each corner of a substantial building. The team interacted only a few minutes each day. I suggested they sit together. When I returned a month later, the project was humming along. The only space they could find was the machine room—cold, drafty, noisy—but they were happy because they were successful.”

Taking it too far — Pair Programming: Don’t force pairing 100% of the time. People need both companionship AND privacy. Prototype alone if needed—but bring the idea back, not the code. Reimplement with a partner.

Slack

Include tasks in your weekly plan that can be dropped if you get behind.

Why slack matters:

Uncertainty is real — Estimates are guesses; some will be wrong
Pressure destroys quality — Teams under constant pressure cut corners
Slack enables improvement — Without breathing room, you can’t experiment

Examples of slack:

Research tasks that can wait
Refactoring that’s beneficial but not urgent
Documentation improvements
Exploratory testing

“If you don’t include slack, you will be scrambling to make your commitments. If you include too much, you won’t be able to say no when asked to do more.”

The right amount of slack lets you meet commitments consistently while maintaining the capacity to improve.

7. Ten-Minute Build and Continuous Integration

Ten-Minute Build

The ten-minute build is a natural constant of software development.

Longer → used less often → missed feedback
Shorter → doesn’t give you time for coffee

Three clues from the practice definition:

Automatically build (not manual)
Whole system (not just what changed)
All tests (not just some)

If you can’t do all three in ten minutes, approximate. Being able to test some of the system is much better than testing none.

Continuous Integration

“Team programming isn’t a divide and conquer problem. It is a divide, conquer, and integrate problem.”

Integration is unpredictable. The longer you wait, the more it costs—and the more unpredictable the cost becomes.

Asynchronous CI (CI server notifies you):

Good: big improvement on daily builds
Missing: no natural reflection time

Synchronous CI (wait together):

Good: forces conversation about what you just did
Good: creates positive pressure for short cycles

Goal: make first deployment “no big deal.”

8. Test-First Programming

Test-first addresses four problems at once:

Problem	How TDD Helps
Scope creep	Explicit objective for what code should do
Coupling/cohesion	Hard to test = design problem, not testing problem
Trust	Clean code that works builds trust with teammates
Rhythm	Red-green-refactor creates natural, efficient flow

“Loosely coupled, highly cohesive code is easy to test.”

The tests you write during test-first take a micro-view. Because of their limited scope, they run fast—thousands can run as part of the ten-minute build.

9. Incremental Design

The old model:

“Put in all the design you can before you begin implementation because you’ll never get another chance.”

XP insight: If the cost of change doesn’t rise catastrophically, big upfront design is waste.

What keeps change cost low:

Automated tests
Continuous practice improving design
Explicit social process
Small, safe steps

The daily question: Where to improve design?

Simple heuristic: eliminate duplication.

“Designs without duplication tend to be easy to change. You don’t find yourself in the situation where you have to change the code in several places to add one feature.”

“The most effective time to design is in the light of experience.”

Taking it too far — Incremental Design: Don’t use “incremental design” as an excuse for NO design. Teams that “pile story on story as quickly as possible with the least possible investment in design” end up with “poorly designed, brittle, hard-to-change systems.” Daily attention to design is required.

War Story — Incremental Deployment:

“A job helping to migrate nine thousand contracts to a new system changed my mind about incremental deployment. After a couple of months we could handle 80% of the contracts, but spent six months trying to get the other 20% working. At the end of the year we hadn’t gotten any contracts deployed and I lost a bonus equal to the cost of a new house. Now I really, really believe in incremental deployment.”

10. Corollary Practices

Prerequisites required—dangerous without primary practices in place:

Practice Dependencies (Corollary → Primary)

Daily Deployment ──────┬── Ten-Minute Build
                       ├── Continuous Integration
                       ├── Test-First Programming
                       └── Near-zero defect rate

Shared Code ───────────┬── Pair Programming (collective ownership)
                       ├── Continuous Integration
                       └── Test-First Programming

Root-Cause Analysis ───┬── Low defect rate (time to invest)
                       └── Whole Team (access to perspectives)

Taking it too far — Daily Deployment: Don’t deploy daily if your defect rate is high. You’ll create chaos. Get defects near zero FIRST with TDD and CI, THEN increase deployment frequency.

Taking it too far — Shared Code: Without collective responsibility culture, “shared code” becomes “nobody’s code.” Quality deteriorates as everyone makes expedient changes, leaving messes. Build the culture FIRST.

Practice	Description	Prerequisite
Real Customer Involvement	Customers on the team	Trust built through primary practices
Incremental Deployment	Gradual replacement of legacy	Low defect rate
Team Continuity	Keep effective teams together	Organizational buy-in
Shrinking Teams	As capability grows, reduce size	Mature team dynamics
Root-Cause Analysis	Five Whys for every defect	Low enough defect rate to invest
Shared Code	Anyone can improve any code	Collective responsibility culture
Code and Tests	Only permanent artifacts	Mature incremental design
Single Code Base	One code stream	Mature build/deploy system
Daily Deployment	Deploy every night	Near-zero defect rate, trust
Negotiated Scope	Fix time, negotiate scope	Customer trust
Pay-Per-Use	Charge per transaction	Business model alignment

Negotiated Scope Contracts

Traditional contracts fix scope and let time/cost vary. XP contracts fix time and cost, but negotiate scope.

Why this works:

Reality: You won’t know exactly what you need until you build some of it
Alignment: Customer and team both want to maximize value delivered
Flexibility: When priorities change, scope can change

Start small: split a big contract into phases, with scope negotiation between phases.

Pay-Per-Use

Charge for system usage, not releases.

“Money is the ultimate feedback.”

Benefits:

Direct connection between value delivered and revenue
Accurate information about what users actually use
Alignment of supplier and customer interests

Even if you can’t implement full pay-per-use, subscription models provide better feedback than one-time license fees.

11. The Five Whys (Root Cause Analysis)

War Story — The $500K Defect:

Example from Beck showing how Five Whys reveals the people problem:

Why did we miss this defect? → Didn’t know balance could be negative overnight
Why didn’t we know? → Only Mrs. Crosby knows, not on team
Why isn’t she on team? → Still supporting old system
Why doesn’t anyone else know? → Not management priority
Why not priority? → Didn’t know $20K investment could have saved $500K

“After Five Whys, you find the people problem lying at the heart of the defect (and it’s almost always a people problem).”

Taking it too far — Root Cause Analysis: Don’t do Five Whys on every defect when you have hundreds. You’ll spend all your time analyzing instead of fixing. Get defect rate LOW first, THEN invest in deep analysis of the remaining few.

12. The Whole XP Team

XP teams include everyone needed to succeed:

Role	Contribution
Testers	Think of what could go wrong, catch mistakes early
Interaction Designers	Shape system’s user interface
Architects	Large-scale refactoring, system partitioning
Project Managers	Facilitate communication, keep the rhythm
Product Managers	Customer surrogate, story writing
Executives	Provide courage, articulate goals, secure resources
Technical Writers	Document for users
Users	Real feedback from real use

People need a sense of “team”:

We belong
We are in this together
We support each other’s work, growth, and learning

Team size thresholds (from Malcolm Gladwell):

12 — maximum for comfortable daily interaction
150 — maximum for recognizing faces

Above these, trust becomes harder and teams should split.

13. Theory of Constraints

XP applies TOC thinking:

Identify the bottleneck — Where is work piling up?
Exploit it — Make sure the bottleneck is never idle
Subordinate everything else — Don’t optimize non-bottlenecks
Elevate — Add capacity to the bottleneck
Repeat — The bottleneck will move

In software, the bottleneck often isn’t coding—it’s communication, trust, or decisions.

Improving typing speed when the constraint is unclear requirements is waste.

14. Planning: Managing Scope

“The goal of planning is to maximize value, not to minimize cost.”

XP planning principles:

Plans are forecasts, not commitments — They will change
Estimation is guessing — Track actuals to improve
Scope varies; time and resources are constraints — Don’t pretend otherwise
Stories enable trade-off conversations — “Do you want this OR that?”

The word “requirement” is problematic:

“Out of one thousand pages of ‘requirements’, if you deploy a system with the right 20% or 10% or even 5%, you will likely realize all of the business benefit envisioned for the whole system.”

15. Testing: Early, Often, Automated

Two kinds of tests:

Type	Who Writes	Purpose
Programmer tests	Developers	Design and documentation
Customer tests	Customers/testers	Acceptance criteria

Both should be:

Automated — Run without human intervention
Continuous — Pass at all times
Fast — Part of the ten-minute build

“XP creates and maintains a comprehensive suite of automated tests, which are run and rerun after every change to ensure a quality baseline.”

16. Designing: The Value of Time

Time makes design decisions more or less expensive:

Decision Type	Early	Late
Architecture	Cheap to change	Expensive to change
Details	Expensive (don’t know enough)	Cheap to change

XP strategy: Defer decisions until the “last responsible moment”—but not later.

The last responsible moment = the point where NOT deciding has a cost.

This doesn’t mean no design. It means design when you have the most information: in the light of experience.

17. Summary: XP at a Glance

Values → Principles → Practices
  ↓           ↓            ↓
Why?      Bridge       What?

The Five Values

Communication — face-to-face, whole team
Simplicity — simplest thing that could work
Feedback — concrete, frequent
Courage — tell truth, act on what you see
Respect — everyone’s contribution matters

Primary Practices (13)

Sit Together, Whole Team, Informative Workspace, Energized Work, Pair Programming, Stories, Weekly Cycle, Quarterly Cycle, Slack, Ten-Minute Build, Continuous Integration, Test-First Programming, Incremental Design

Corollary Practices (11)

Real Customer Involvement, Incremental Deployment, Team Continuity, Shrinking Teams, Root-Cause Analysis, Shared Code, Code and Tests, Single Code Base, Daily Deployment, Negotiated Scope, Pay-Per-Use

18. Quick Reference

### XP: Beck's Principles

**Core insight:** Software development is about people, relationships,
and continuous adaptation.

**Five Values:**
1. Communication - face-to-face, whole team
2. Simplicity - simplest thing that could work
3. Feedback - concrete, frequent, from system and customers
4. Courage - tell truth, act on what you see
5. Respect - everyone's contribution matters

**Key Practices:**
| Practice | Purpose |
|----------|---------|
| Pair Programming | Real-time code review, shared knowledge |
| TDD | Design feedback, scope control, confidence |
| CI | Small batches, cheap integration |
| Ten-Minute Build | Frequent feedback |
| Weekly Cycle | Regular rhythm, deployable every week |
| Incremental Design | Design in light of experience |

**Planning:** Scope varies; time and resources are fixed.
Maximize value, not minimize cost.

**Testing:** Two kinds - programmer tests (design) and customer tests
(acceptance). Both automated.

**Change:** "Everything in software changes."
Adapt continuously through small corrections.

19. Connection to Khorikov (Testing)

Beck (XP)	Khorikov (Unit Testing)
Test-First Programming	Output-based testing preferred
Programmer tests	Unit tests on domain logic
Customer tests	Integration tests on behavior
“Hard to test = design problem”	“Test couples to implementation = fragile”
Incremental design	Refactoring with test coverage

Shared insight: Tests are a design tool, not just verification.

Both authors agree: if you need mocks for internal collaborators, that’s a design smell.

20. Connection to Ousterhout (Design)

Beck (XP)	Ousterhout (Design)
Simplicity value	Fight complexity
Incremental Design	Design it twice
“Eliminate duplication”	Deep modules
Baby Steps principle	Small investments
Continuous Integration	Reduce unknown unknowns

Shared insight: Design should happen continuously, not upfront.

Both see design as ongoing refinement. Ousterhout’s “strategic programming” (invest 10-20% extra) aligns with Beck’s “incremental design” (daily attention).

21. Connection to Tran (FP)

Beck (XP)	Tran (FP)
Simplicity	Abstraction reduces complexity
Small methods	Small functions
Eliminate duplication	Reuse through composition
Test-First	Pure functions are easy to test

Shared insight: Simplicity requires discipline and continuous attention.

Both emphasize that simple solutions require more thought, not less. “Simplest thing that could work” and “abstraction” are both intellectual work.

22. Key Quotes

“XP is about social change.”

“Technique also matters. We are technical people in a technical field.”