Notes about Extreme Programming Explained
I've wanted to read Extreme Programming Explained for quite some time, but I couldn't get my hands on the first edition from 1999, which is written in a less politically correct style than the second edition from 2004. I finally managed to get it, so I'm now writing notes for myself as I read it.
Foreword
The foreword by Erich Gamma starts off with a witty irony, suggesting that a software methodology based on putting programming front and center surely can't work. What caught my attention was that even back in 1999, Gamma was working in a distributed team that exchanged specifications, tests, bug reports, and everything else in the form of code.
Preface
For some people, Extreme Programming (XP) is just common sense. So why the word “extreme” in the name? Kent Beck took several proven programming practices and pushed them to the extreme:
- Code reviews are good → Pair programming
- Testing is good → Unit testing (by programmers), functional testing (by customers)
- Design → Refactoring
- Simplicity → Simple design
- Architecture → Metaphor
- Integration testing → Continuous integration
- Short iterations → Really short iterations
XP is a discipline meant for a team of average programmers who are relatively independent from the rest of the company. None of XP’s practices are new—these programming techniques have been around for decades, and the management ones for centuries. XP simply brings them together under one umbrella.
What I find interesting is that many of these techniques still haven’t become widely adopted even by the year 2025. The world is only gradually discovering what this book already discussed back in 1999.
Beck uses a metaphor of forest people and mountain people based on the research of anthropologist Colin Turnbull. Among the forest people, who had everything in abundance, positive qualities developed. In contrast, among the mountain people, there was a lot of violence, betrayal, and similar behavior.
It seems to me that today, Beck and his daughter are trying to reincarnate and reformulate this metaphor into a contrast between forest people and desert people. XP is meant to resemble the story of the forest people—developing software as one would if they had enough time for everything.
At the end of the preface, Beck admits that for the last 15 years, he has basically just been writing down what he observed from his colleague, Ward Cunningham.
Part I - The Problem
Beck states that the approach will move from theory to practice, aiming to invent a new discipline for software development. He tries to justify the necessity of XP through theoretical foundations—probably to make the book sound scientifically valid.
That part didn’t really interest me, and I don't even think Beck needs it. Maybe he needed it back in 1999.
Chapter 1. Risk: The Basic Problem
The fundamental problem of software projects is risk. XP attempts to mitigate risk through the following strategies:
- Missing deadlines – XP uses short release cycles and always focuses on the highest-priority task at any given moment.
- Project cancellation – Small, frequent releases reduce the impact of a potential project shutdown.
- Slowing down over the years – XP maintains a project in top shape through a suite of tests and a simple design, preventing long-term decay.
- Too many production defects – XP enforces a mandatory test suite to catch bugs early and reliably.
- Misunderstood business requirements – With a customer embedded directly in the team, the risk of miscommunication is significantly reduced.
- Changing business needs – Short iterations allow the business side to change requirements frequently and with minimal disruption.
- Unnecessary features – XP ensures that only the top-priority tasks defined by the business are worked on.
- Team turnover – XP doesn’t expect the impossible from developers. With realistic estimates and tight team collaboration, the system can better absorb changes in personnel.
Chapter 2. A Development Episode
This chapter presents a day in the life of XP programmers.
They work in pairs. Whenever they encounter any uncertainty, they immediately ask the on-site customer—who is part of the team and available to talk—so they can discuss the requirements for a moment.
When they come up with an improvement idea through refactoring, they don’t implement it right away. Instead, they jot it down in a to-do list. They write down all three possible implementation options to ensure they don’t forget any of them.
At the end of the day, they merge their changes—developed using Test-Driven Development (TDD)—into the shared branch.
Chapter 3. Economics of Software Development
Beck mentions viewing software economics through the lens of stock options—an idea he later revisits in his more recent book Tidy First?.
He answers the question of when to use XP: it's most suitable when requirements are vague or subject to change.
In such an environment, it's often smarter to wait rather than implement a speculative feature or add flexibility preemptively. The reason is simple: there’s a high chance that the investment won’t pay off, and XP encourages minimizing such waste by responding to change instead of predicting it.
Chapter 4. Four Variables
There are four variables in a software project: cost, time, quality, and scope. Some managers believe they can dictate all four — but the result is inevitably poor-quality software delivered late.
On Quality
There’s no point in compromising on quality. Every compromise ultimately slows the project down. It might seem at first like reducing quality gives you a short-term speed boost, but this shortcut will catch up with you. Soon, it becomes harder and harder to add new features, and the project grinds to a halt.
On Cost
Cost is often tightly constrained from above and hard to move. Increasing cost also doesn't bring immediate returns. Ironically, for the sake of status, some managers believe that hiring 150 developers looks better than having 10 developers finish the same project in half the time.
If you're going to raise costs, it's more effective to invest in equipment—like faster computers, better office space, and improved tools—rather than more headcount.
On Time
Deadlines are usually dictated externally and aren’t easy to shift.
On Scope
This makes scope the most important and flexible variable in software development.
Business requirements are never fully clear at the beginning. Customers never tell you exactly what they want. And if you miss a critical feature in a release, customers will get upset.
XP handles this risk through:
-
Estimation – providing feedback to the customer on how much a request will cost in effort, helping them prioritize realistically.
-
Prioritization – always implementing the most important features first, ensuring you never end up completing something unimportant at the expense of something essential.
Chapter 5. Cost of Change
XP promises to flatten the cost-of-change curve over time. At the same time, this flattened cost-of-change curve is what enables XP to work.
If the cost of making changes were sky-high, you’d be crazy not to do extensive upfront planning and architecture. But if changes stay cheap over the course of the project, then an adaptive, iterative approach like XP becomes viable—and even preferable.
Technical Enablers of a Flat Cost Curve
To flatten the cost of change, XP relies on several technological practices:
-
Objects help – Object-oriented design supports flexible structures.
-
Message passing – Encourages decoupling and future-proofing, making changes cheaper and more localized.
Why XP Code Remains Easy to Modify Even After Years
Based on previous XP projects, the following are key reasons why XP codebases remain maintainable and change-friendly even after years:
-
Simple design – No unnecessary components are introduced. This means there’s less "dead weight" to refactor or understand.
-
Automated tests – They ensure the system still works after each change, giving developers confidence to refactor aggressively and safely.
-
Frequent design change practice – Continuous experience with evolving the design makes developers better at keeping the code clean and malleable.
Chapter 6. Learning to Drive
Beck compares software development to driving a car.
You don’t drive by locking the steering wheel in place—you drive by constantly paying attention to where you're going and making small adjustments to the direction, a little to the left, a little to the right.
The only constant is change.
This metaphor captures the core of XP: successful development isn’t about rigid plans, but about continuous feedback, adaptation, and course correction.
Chapter 7. Four Values
1. Communication
The first XP value is communication.
Beck argues that nearly all problems in software projects can be traced back to someone not telling someone else something important.
Practices like testing, pair programming, and estimation naturally force developers and managers to talk to each other, making communication an integral part of the workflow.
2. Simplicity
The second value is simplicity.
XP encourages a development style guided by the question: “What’s the simplest thing that could possibly work?”
XP bets that it’s cheaper to do something simple today—even if you have to pay a little more to change it tomorrow—than to build a more complex version today that might never be used.
3. Feedback
The third value is feedback.
Optimism in programming is essentially a form of gambling.
Feedback is the antidote. It helps keep the project grounded in reality and aligned with what’s actually needed.
4. Courage
The fourth value is courage.
One of the challenges with XP’s incremental design strategy is getting stuck on local maxima—you can only improve something so far by small tweaks.
Sometimes, it takes courage to make a bigger, more disruptive change.
However, courage without the first three values—communication, simplicity, and feedback—would simply amount to reckless hacking.
5. Respect (Underlying Value)
Beneath all four core values lies a deeper one: respect.
If team members don’t care about each other, no amount of methodology can save the project.
Respect is the human foundation that enables XP to work in practice.
Chapter 8. Basic Principles
1. Rapid Feedback
Rooted in psychology, this principle emphasizes that the faster the feedback, the faster the learning. XP practices like continuous integration, testing, and short iterations are all designed to tighten this feedback loop.
2. Assume Simplicity
Always assume that every problem has an almost ridiculously simple solution.
This can be hard for programmers to embrace, as it goes against the urge to over-engineer. However, from the software-as-stock-options perspective, it’s more economical to build something simple and adapt later than to plan everything up front.
3. Incremental Change
Big, sweeping changes are risky and often fail. XP advocates for delivering software in small, cohesive steps, with each change building steadily on the last.
4. Embrace Change
Change is not a threat—it’s the essence of software development.
XP recommends always working on the most pressing problem rather than protecting outdated plans.
5. Quality Work
Quality is not optional.
There are only two viable levels of quality:
- Excellent
- Insanely excellent (especially in life-critical systems)
- Poor quality leads to delays, rework, and ultimately project failure.
6. Teach Learning
Focus on practices and strategies that promote continuous learning, both for individuals and the team.
7. Small Initial Investment
Starting with a large budget and massive team is often a red flag.
XP encourages beginning lean, growing only as needed.
8. Play to Win
There’s a big difference between:
-
Playing to win: Doing what helps the project succeed, even if it’s unconventional.
-
Playing not to lose: Following rules to avoid blame, even when it harms the project (e.g. excessive documentation just for cover).
9. Concrete Experiments
Every major design decision should be backed by practical experiments, ideally validated with tests.
10. Open, Honest Communication
There should be no secrets in the team—whether it's admitting we're behind schedule or revealing technical debt. Hiding problems kills collaboration.
11. Work With People’s Instincts
Design workflows that feel natural, instead of fighting human behavior. For example, encourage working together instead of imposing rigid processes.
12. Accepted Responsibility
Responsibility should not be assigned top-down.
It should be voluntarily accepted by team members, empowering autonomy and accountability.
13. Local Adaptation
Everything in XP is subject to adaptation to the local context. There is no one-size-fits-all approach.
This book offers guidance, not gospel.
14. Travel Light
Carry only what you truly need.
Keep processes, documentation, and design as minimal and valuable as possible, so you're always ready to refactor or pivot.
15. Honest Measurement
Track metrics that reflect your goals, not vanity numbers.
Measure what actually correlates with team health and project success.
Chapter 9. Back to Basics
Coding is the one activity we can’t do without. It's central to everything in XP.
- The most important thing we want from code is learning. Code teaches us what works and what doesn’t.
- Code allows for concise and clear expression of ideas.
- Code is also a medium for writing tests—both to validate logic and to clarify intent.
In XP, coding is not just a means to deliver functionality—it's also a tool for discovery, communication, and validation.
In XP, if something can’t be measured or verified, it might as well not exist.
- Testing tells us when we're done.
- We have a duty to write every test we suspect won’t pass on the first attempt.
- Surprisingly, coding with automated testing is faster than coding without it
- XP includes both:
- Programmer-written unit tests
- Customer-specified functional tests
Even performance and compliance with standards can be tested. The discipline of testing leads to faster feedback, better design, and more confident iteration.
- The only way to get those answers is to listen—to customers, teammates, and the system itself.
- Listening builds shared understanding, aligning technical work with business goals.
It’s not just about hearing words; it’s about grasping intent, context, and nuance.
Design organizes the system's logic and keeps change affordable over time.
- Good design ensures that a change in one part of the system doesn’t ripple into others.
- It places logic close to the data it manipulates, making reasoning and maintenance easier.
- In contrast, bad design spreads logic thinly across many layers of indirection, making it hard to understand what’s happening and why.
In XP, design isn’t a phase—it’s a continuous, iterative activity. The goal is not to predict the future perfectly, but to keep the system malleable and expressive as it grows.
Part II: The Solution
Chapter 10. A Quick Overview
In Extreme Programming (XP), each practice has its weaknesses—but these are intentionally counterbalanced by other practices. This interdependence forms a kind of safety net, where no single practice is expected to carry the entire weight of the methodology on its own.
Here’s an overview of the core XP practices and how they contribute to the whole system:
🎯 The Planning Game
Business stakeholders are responsible for:
- Scope
- Priorities
- Release composition
- Release deadlines
Technical team members are responsible for:
- Effort estimation
- Technical consequences
- Process design
- Planning details
This division ensures that planning is a collaborative negotiation, not a top-down mandate.
📦 Small Releases
Each release should be:
- The smallest possible increment,
- Yet still make sense as a complete unit.
Delivering half a feature just to hit a short iteration is discouraged—XP values completeness, however small.
🔁 Metaphor
Each XP project is guided by a shared metaphor—a consistent mental model for how the system works.
Example: "Our system is like a spreadsheet."
- This metaphor influences naming and structure in the code.
- It acts as a replacement for traditional architecture documents, making the system easier to understand and communicate.
🧱 Simple Design
The "correct" design, in order of priority:
- All tests pass
- No duplicated logic
- Every intent clearly expressed in code
- Minimal number of classes and methods
You should remove design elements as long as you’re not violating the first three rules.
✅ Testing
In XP, a feature without an automated test simply doesn’t exist.
- Tests validate functionality.
- Tests act as specifications.
- Tests provide safety for future changes.
🔧 Refactoring
Refactor only when the system demands it, not preemptively.
- Triggers include repeated duplication or overly complex designs.
- Refactoring is tightly coupled with testing and pair programming for safety.
👯 Pair Programming
All production code is written by two developers at one machine.
- One types (the “driver”), while the other thinks strategically.
- The navigator questions assumptions, proposes simplifications, and anticipates issues.
- This encourages shared understanding, code quality, and real-time code review.
🛠️ Collective Ownership
Everyone has full responsibility for the entire codebase.
- Anyone can improve or fix any part of the system.
- Reduces bottlenecks and silos, and encourages team-wide accountability.
🔄 Continuous Integration
Code is:
- Integrated and tested within hours, or at most daily.
- This ensures conflicts are small and feedback is immediate.
⏰ 40-Hour Week
No one should work more than one week of overtime in a row.
- Sustainable pace prevents burnout.
- Quality and decision-making degrade under chronic stress.
👨💼 On-Site Customer
A real customer representative sits with the development team full-time.
- This rule often meets resistance: "Customers are too valuable to spare."
- But XP flips that logic: If your project can't justify having a customer available, maybe it’s not worth doing.
- The value of fast, correct decisions outweighs the productivity loss of one or two individuals.
🧾 Coding Standards
The team collectively defines and voluntarily adheres to a consistent coding style.
- This ensures readability and maintainability across the team.
- Standards prevent stylistic arguments and help support collective ownership.
Together, these practices form a cohesive system, where each compensates for the potential pitfalls of the others.
XP isn't about doing one or two of these things—it's about doing them together so the team can thrive in the face of change.
Chapter 11. How Could This Work?
Chapter 12. Management Strategy
No single person has enough knowledge to make all the right decisions alone. In XP, the manager doesn’t assign tasks—they simply remind the team of what needs to be implemented, and then leave it to the development team to choose which tasks to take on.
The attitude of management shouldn’t be about forcing the team to do their job, but rather about helping them achieve even better performance.
Anything a manager needs from developers should not take up much of their time.
The primary tool of XP management is metrics.
Metrics should be updated as they approach 100%, to ensure they remain relevant and useful over time.
Another key tool is tracking progress.
This should happen in the background and shouldn’t interrupt or annoy the team.
Twice a week is more than enough to stay aligned.
The coach’s role is to encourage everyone to make good technical decisions.
Traditionally, XP projects attract lots of “toys”:
- Whiteboards
- Sticky notes
- Standing desks
- And more
The coach is responsible for providing these tools—and occasionally, providing food as well.
Their mission is to create an environment where the team can thrive.
If intervention becomes necessary, it must be done with deep humility.
The manager’s role is not to tell people what to do, but rather to point out the need for change.
And one of the most difficult duties of management is to shut down a project that’s dying—a painful but sometimes essential responsibility.
Chapter 13. Facilities Strategy
This chapter features a photo of a few desks allocated to the C3 Payroll team, the birthplace of Extreme Programming (XP).
In the image, programmers are seated in pairs, engaged in pair programming. The space is well-equipped: there’s ample room, whiteboards, sticky notes, and other collaborative tools. It’s an environment designed to foster communication, focus, and adaptability.
Kent Beck was initially brought in as a Smalltalk expert, but the most impactful advice he gave was to rearrange the furniture.
The team was physically separated from other teams, creating a space they could shape and own.
Having control over their environment was the first step toward feeling in control of the project itself.
This seemingly simple change contributed significantly to creating the conditions for XP to flourish.
Chapter 14. Splitting Business and Technical Responsibility
- Too much power on the Business side leads to:
- Non-negotiable feature requirements, regardless of technical implications.
- Often, the lowest-priority features carry the highest risk.
- This results in bloated scopes, creeping deadlines, and an overwhelmed development team.
- Too much power on the Development side leads to:
- Overuse of the latest and flashiest technologies.
- Pursuit of unnecessary technical sophistication that adds risk but no value.
- A system that may be elegant or modern, but out of sync with what the business truly needs.
To avoid these pitfalls, XP advocates for a clear separation of responsibilities between Business and Development:
🏢 Business is responsible for:
- Project scope and timing
- Feature prioritization
- Exact feature definitions and trade-offs
💻 Development is responsible for:
- Effort estimation
- Assessment of technical implications
- The development process and chosen practices
- Day-to-day engineering decisions
Even though technology choice may appear to be a purely technical decision, it is, in fact, a business decision—because the business will need to live with that technology for the entire lifecycle of the project.
Sometimes, the most valuable business feature is also the hardest one to build.
In that case, the development team doesn’t push back endlessly or wait for perfection—they just start.
They begin implementing it, even if the path isn’t fully clear. The goal is to deliver value quickly and iteratively, breaking down complexity into manageable steps.
This balanced, collaborative approach is what allows XP teams to deliver risky, valuable features reliably, while keeping both business and technical concerns in harmony.
Chapter 15. Planning Strategy
We should only plan work for the short, foreseeable future. Responsibility must be accepted, not assigned. The person who accepts responsibility is the one who estimates the effort. Dependencies between tasks should be ignored. If we always work on the most important task, dependency issues usually resolve themselves. If planning is done purely for prioritization, it requires far less detail than planning for development.
The goal of the Planning Game is to extract the greatest possible value from the software produced by the team. Some of the best Business players are expert users. The game has three phases—exploration, commitment, and steering.
The exploration phase gives the team a sense of what lies ahead. During this phase, user stories are written and their effort estimated. The development team asks the Business for clarification wherever requirements are missing. The final part of the exploration phase is breaking down user stories—either because the team can’t estimate them as a whole or because the Business realizes that part of the story is less important than the rest.
The commitment phase has four steps. The Business sorts the user stories by value into must-haves, should-haves, and nice-to-haves. The development team ranks the stories by technical risk into perfectly estimated, loosely estimated, and unestimable. The development team informs the Business of how fast they can code in ideal engineering days. The Business then chooses the scope either by setting a date or by selecting story cards and calculating a projected date from them.
The steering phase also has four steps. At the beginning of each iteration, the Business selects the highest-value stories that will fit within the available effort. If the development team realizes they are slower than expected, they inform the Business of their new velocity, so the Business can re-select the most important stories to keep in the release. If the Business needs a new story mid-release, they can submit it, the development team estimates it, and the Business can swap it in for a story of similar value. If the development team sees that an estimate is no longer accurate, they can re-estimate the stories and update the plan accordingly.
A multi-month release plan is completed in just a week. This is possible in XP because larger user stories are preferred, and estimates are made based on experience.
Chapter 16. Development Strategy
Unlike the strategy for management, the strategy for development is a radical departure from traditional approaches. We create software only for today’s problems, trusting that we’ll be able to solve tomorrow’s problems when they arrive.
XP uses the metaphor of programming to describe its activities. But putting these activities into practice is hard. Under pressure, people often fall back on old bad habits.
Continuous Integration tells us that no code should remain unmerged for more than a few hours. By the end of the day, all code is merged into the planned release branch, and all tests must run at 100%. The production build is no big deal—any developer can produce it at any time because it gets built every day.
Collective Ownership is a somewhat crazy idea: anyone can modify any part of the codebase. Without tests, we’d be insane to attempt this. But with tests—after enough time spent writing them—the test suite reaches a level of quality where this becomes manageable. Frequent integration of changes into the release branch is also necessary, and that’s exactly what we do. Collective ownership also has a psychological effect: it discourages developers from introducing unnecessary complexity, since someone else may be working on that code tomorrow. It also helps distribute code knowledge across the entire team.
Pair Programming deserves a book of its own. It’s a skill you can keep improving for a lifetime. It’s not about one person typing while the other watches—it’s a dialogue, and at the same time, a learning experience. One of the greatest benefits of pair programming is that it enables the other practices to function. Without it, people tend to revert to old habits under pressure.
Chapter 17. Design Strategy
We eliminate flexibility that serves no purpose. The design must always be the simplest possible that can pass the current set of tests. In this, XP runs counter to the instincts of many programmers.
We begin with a test that tells us when we're done. Even at the test-writing stage, we must design an ideal API.
Then we implement just enough code to make the test pass.
We repeat.
When we see an opportunity to simplify the design, we take it.
If we identify a need for a large refactoring, we must carry it out in small steps. A major refactor in an XP project can unfold gradually, over the course of a year.
The simplest possible design has four qualities, in order of importance:
- The system communicates everything you want it to communicate.
- The system contains no duplication.
- The system has the fewest possible classes.
- The system has the fewest possible methods.
So rather than avoiding rework, XP embraces it.
XP doesn’t rely on extensive diagrams—or at least, it doesn’t store them. Diagrams are drawn on the whiteboard.
If a design question comes up that’s best answered through the code, designers are expected to code.
For the first iteration, choose user stories that you think will force you to build the full architecture. Then put on blinders and implement them using the simplest design possible.
It might not be the design you originally imagined, but you’ll have learned something along the way.
XP is about doing the simplest thing today, and trusting that you’ll be able to change it tomorrow.
Chapter 18. Testing Strategy
We write tests before writing production code. We run them frequently. We also write functional tests from the customer’s perspective. Ugh. Nobody likes to talk about testing—the ugly stepchild of software development. If it were truly possible to develop without tests, we’d gladly throw them out.
But in XP, tests must be automated and isolated. We should test the things that could actually fail. Testing is a bet that pays off when our assumptions are wrong—either a test passes when it shouldn’t, or it fails when it should have passed. Ideally, we’d only write tests that reveal this kind of value—but since we can’t know in advance which tests will do that, we write tests that might.
Tests are written by both programmers and customers.
Programmers write tests method by method.
If the API is unclear in any way, we write a test first—the API becomes clear through that process.
If the implementation is uncertain, we write a test that forces us to implement it.
If we think of an unusual use case, we write a test that expresses that scenario.
If we’re about to refactor code that lacks tests, we write the tests first.
Programmer tests must always pass 100%—no exceptions.
Customers write tests story by story.
They answer the question: What has to happen for me to be sure this story is complete?
These functional tests aren’t required to pass 100% of the time—their success is measured in percentages.
Customers typically can’t write these tests on their own, which is why XP teams usually include a tester.
The tester’s job is to transform the customer’s vague testing ideas into real, automated, and isolated tests.
There are also other types of tests.
A parallel test confirms that a new system behaves the same as the old one.
A stress test simulates the highest possible load.
A monkey test checks whether the system behaves reasonably when fed nonsensical or random inputs.
Part III. Implementing XP
Chapter 19. Adopting XP
Adopt XP one practice at a time. Identify your biggest problem, and solve it using the XP approach. Once that problem is no longer your biggest, repeat the process.
The two most obvious practices to start with are Testing and the Planning Game. Many projects suffer from poor quality or from a disconnect between Business and Development.
As a step -1, you might start by rearranging the furniture to support pair programming and to make space for the customer to sit with the team.
Step 0 is then buying some snacks.
Chapter 20. Retrofitting XP
Start your adoption of XP with testing and planning.
If you need to add functionality to untested code, begin by writing tests.
If you're fixing a bug, write a test that reproduces the bug first.
If you want to refactor, make sure the code is covered with tests beforehand.
Approach XP design incrementally, in small steps.
While adding new functionality, stay alert to opportunities for small refactorings.
The parts of the system you touch most often will soon start to resemble well-written code.
If you’re a manager, begin noticing the decisions that should have been made by a programmer or a customer, instead of yourself.
As a programmer, take a break now and then. Spend a few hours coding something just for yourself—and then throw it away.
If your project is in bad shape, XP is not a magical rescue.
Sometimes the best course of action is to start over from scratch.
Chapter 21. Lifecycle of an Ideal XP Project
An ideal XP project goes through a rapid initial phase leading up to the first release, followed by years of production support and incremental improvements, and eventually ends in retirement, once the system is no longer needed.
Pre-production is an unnatural state for a project. The exploration phase is considered complete when the customer feels confident they have all the user story cards required for the first release, and the development team can’t improve the estimates any further without actually writing the code. During this phase, it can be useful to bring in a technical consultant or a specialist in the chosen technology, though their advice should occasionally be taken with a grain of salt. Developers should also test the performance limits of the system during exploration.
This phase is valuable not just for the team, but also for helping customers learn what needs to be specified for developers—and just as importantly, what doesn't. If the developers already know each other and the technology well, the exploration phase can be quick—a matter of weeks. But if both the team and the tech are new, it might take a few months. If it stretches beyond that, it may be time to find a smaller but real project with some sense of urgency to get things moving.
The plan for the first release should fall within a range of 2 to 6 months. If it’s less than two months, we likely won’t deliver anything significantly valuable to the business. If it’s more than six, the risk becomes too great. If, during development, we discover we’re diverging from the plan, something must change—either the scope or the process.
Shorter iterations are often helpful before production launch, especially for tuning performance. After the first release, a slowdown in development should be expected—not because the team stops working, but because adding new features now carries the risk of breaking production, which wasn’t a concern earlier.
Maintenance is the normal state of an XP project. Being in production typically reduces development velocity. It’s common to lose up to a third of development time to production support, and this impact should be measured. Support duties should rotate among all developers. New features should be gradually introduced into production, even if they’re not used right away—this keeps deployments steady and controlled.
A project ends when the customer is satisfied and can’t think of anything new to add. Another reason for ending is when continuing becomes economically unviable—when the cost of adding features outweighs the benefit. This usually happens when entropy catches up with the system. XP doesn’t pretend to be a magic bullet; it simply hopes to delay the effects of entropy far longer than traditional approaches would allow.
Chapter 22. Roles for People
A football team works best when certain roles are filled. Positions—both in football and in any team—are conventions, not laws of nature. Sometimes, having multiple roles assigned to the same person causes problems.
If programmers were always capable of deciding both short-term and long-term priorities, no other technical roles would be needed on a project. The first core value for a programmer is communication.
However, nerds aren’t typically known for their communication skills—and this is exactly why XP forces us to communicate.
The customer is the other half of the fundamental XP duality. A customer must be able to make decisions:
“This is more important than that.”
“This part of the story is enough.”
They must learn to write user stories and to test those stories in such a way that they know which tests give them the confidence that a story is done.
The tester supports the customer by helping write tests, regularly executing them, and reporting functional test results to the whole team.
The tracker monitors whether the project is on schedule.
By the middle of each iteration, they should already know whether the team is on track or not.
The key is to do this in a way that minimally disturbs the team.
The coach is responsible for the overall process.
They observe and call out deviations from the agreed process.
Their work is mostly indirect—too many direct interventions will make the team dependent instead of self-reliant.
For example, it’s better to suggest a test whose implementation forces the team to improve the design than to simply prescribe a better design outright.
But sometimes, the coach must be very direct, even to the point of rudeness. Programmers are often valuable because of their confidence and aggressiveness, and those traits may require equally strong guidance.
The big boss must be prepared to hear the truth.
When developers say they're overwhelmed or falling behind, it's not just complaining—
it's a signal to give management as much time as possible to respond and take corrective action.
Chapter 23. 20-80 Rule
XP has so many synergies between its practices that it only works at 100% effectiveness when all of them are used together.
When only a subset of the practices is adopted, you might gain just 20% of the benefits.
The power of XP lies in its interconnectedness—each practice supports and reinforces the others. Remove a few, and the system becomes fragile, incomplete, and prone to failure.
Chapter 24. What Makes XP Hard
It’s primarily emotions—especially fear—that make XP hard. XP is simple in its details, but difficult to execute.
The reason to dedicate a senior technical person solely as a coach is because maintaining balance in the XP process is challenging.
Most software teams are fully capable of implementing XP.
But it’s hard to practice simple design—a team must not settle for anything less than the simplest possible solution.
It’s also hard to admit you don’t know something, and hard to collaborate closely day in and day out.
In some company cultures, it’s especially hard to admit there’s a problem, because problems are seen as weaknesses or complaints rather than opportunities for improvement.
It’s easy to corrupt the XP process through small deviations from the original ideas.
Take planning, for example: the original intent was simple and clear:
- Sign up for a task.
- Estimate it yourself.
- Rebalance if someone ends up with too much.
But this got distorted into:
- Let’s estimate all the tasks together (where the author of the task doesn’t estimate their own work).
- Then pick a task.
These small shifts may seem innocent, but they erode responsibility, ownership, and the clarity of intent that XP depends on to thrive.
Chapter 25. When You Shouldn't Try XP
Some XP practices are valuable under all circumstances—notably Testing, and likely Planning as well.
However, any company that struggles with gradual course correction—that needs to aim the car straight at a distant goal and stay locked on that trajectory—is unlikely to enjoy XP. One such form of rigid aiming is heavy upfront specification.
Another type of company culture that clashes with XP is one that expects frequent overtime from developers.
XP also doesn’t scale well to very large teams—it’s not a good fit for a hundred developers.
With ten developers, though, it absolutely works.
The biggest bottleneck in scaling XP is often the integration process.
And finally, XP is not compatible with certain types of distractions—you can’t do XP with a crying baby in the room.
Chapter 26. XP at Work
XP can adapt to different types of contracts with just minor modifications. For example, a fixed price/fixed scope contract naturally shifts into a more flexible fixed price/fixed date/roughly fixed scope model. In this form, XP operates almost like a subscription service, delivering value through smaller, incremental releases.
XP often works better than typical outsourcing, because it gives the customer something tangible—automated tests that describe how to maintain the system over time.
Beck isn’t enthusiastic about outsourcing in general. Instead, he recommends gradually replacing the technical XP team with people from the customer’s organization. This transition should be slow and incremental. Beck calls this approach “insourcing.” By the end of the contract, the entire team belongs to the customer.
Sometimes, XP teams are paid by the hour, and in such cases, the rest of the XP process works as usual.
And what about frameworks? XP doesn’t prioritize up-front reuse. It focuses on building applications that are actually used.
If, over time, the team discovers reusable patterns, that’s when it becomes appropriate to extract a framework—not before.
Chapter 27. Conclusion
All methodologies are built around fears. They aim to establish practices that prevent those fears from becoming reality. XP is no exception. What sets XP apart is which fears it chooses to address.
XP is Kent Beck’s creation, and so it reflects his personal fears:
- Working on something that doesn’t matter
- Projects being cancelled due to lack of progress
- Bad business decisions made by technical people
- Bad technical consequences of business decisions
- Wasting time working when he should have spent it with his children
- Doing work he isn’t proud of
At the same time, XP also embodies the things Beck is not afraid of:
- Programming itself
- Changing one’s mind
- Making progress without needing to know everything about the future
- Relying on others
- Allowing the analysis and design of a running system to evolve
- Writing tests
XP is paradoxically prepared for any kind of business change precisely because it doesn’t try to preemptively guard against them.
By not attempting to outsmart change, XP cannot be caught off guard by it.
Comments