When XP Fits

XP was designed for projects where requirements change frequently. If you don't know exactly what to build, XP helps you discover it.

Signals of high uncertainty:

• Customers can't articulate their needs precisely
• The market is shifting
• You're building something new, not replicating something known
• User feedback regularly changes priorities
• Competitors are innovating, forcing you to adapt

In these environments, traditional approaches fail. Detailed up-front design becomes obsolete before implementation. Big releases miss the mark because requirements changed.

XP embraces change. Small releases get feedback fast. Simple design avoids over-investment. The planning game adjusts continuously. Uncertainty isn't a problem—it's expected.

If your requirements are truly stable and well-understood, XP still works, but the value proposition is different. You gain quality and team health, but the adaptability benefits are less pronounced.

XP shines when code will live for years. The investment in technical practices pays off over time.

Why long-lived systems benefit from XP:

• Tests: Catch regressions as the system evolves
• Refactoring: Keep the design clean as requirements change
• Collective ownership: Spread knowledge as team members come and go
• Simple design: Avoid accumulating complexity
• CI: Maintain integration discipline as the team grows

If you're building a prototype that will be thrown away, XP's investment in quality may not pay off. But most "prototypes" become production systems. Most "temporary" code lives for years.

The bet: Assume your code will live longer than you think. Invest in quality from the start. If you're wrong, you've lost a little time. If you're right (and you usually are), you've saved years of pain.

XP requires close collaboration. Pair programming, planning games, and collective ownership only work when people work well together.

Signs your team is ready:

• People communicate openly, including about problems
• There's trust between team members
• People help each other without being asked
• Disagreements are resolved constructively
• The team has psychological safety

If your team lacks these qualities, XP practices will feel forced and awkward. You may need to build team health before adopting XP—or use XP practices to build team health gradually.

XP can improve collaboration, but it can't force it. A team of people who won't share code won't suddenly embrace collective ownership. A team afraid to admit mistakes won't benefit from transparency.

The culture has to support the practices—or at least be willing to change.

XP requires an available customer—someone who can answer questions, make priority decisions, and provide feedback.

Without customer availability:

• Developers guess at requirements (often wrong)
• Priorities are unclear (everything seems important)
• Feedback comes too late (features are built wrong)
• The planning game can't function

Customer availability means:

• Questions answered in hours, not days
• Priority decisions made when asked
• Regular feedback on delivered work
• Engagement with the planning process

If your customers are unavailable, XP becomes difficult. You can use a product owner as a proxy, but someone must play the customer role effectively.

Organizational dysfunction often prevents customer availability. The customer is too busy, too political, or too distant. These are organizational problems to solve, not XP problems.

Some XP practices assume modern software development contexts. They may need adaptation in other environments.

TDD assumes:

• You can write automated tests (not all environments support this easily)
• Tests run quickly (slow tests make TDD painful)
• The testing culture exists (team believes in testing)

CI assumes:

• Code can be integrated frequently
• Build and test can be automated
• Trunk-based development is feasible

Pair programming assumes:

• Work happens at a computer
• Two people can see the same screen
• The work benefits from real-time collaboration

In most software development, these assumptions hold. But embedded systems, hardware-dependent code, or highly regulated environments may need practice adaptation.

The principles remain. The specific practices may change.