When XP Struggles

Many software projects have contracts that fix scope, date, and price. XP's iterative approach conflicts with this.

The XP position: You can't fix all three (scope, date, resources). Something must flex. XP prefers flexible scope with fixed quality.

The contract reality: Clients want to know exactly what they'll get, when, for how much. Traditional contracts promise this.

Tensions:

• XP says "we'll discover the best solution together." Contracts say "build exactly this."
• XP says "change is welcome." Contracts say "changes cost extra."
• XP says "ship early and iterate." Contracts say "deliver everything at the end."

Options:

• Negotiate better contracts: Time-and-materials, outcomes-based, or scope-flexible agreements
• Use XP internally: Even with a fixed contract, internal practices can be XP
• Manage expectations: Communicate that early delivery of partial scope is possible

XP in contract environments isn't impossible, but it requires client education and contract negotiation.

XP was designed for co-located teams. It can work remotely, but only with good communication tools and culture.

Challenges:

• Pair programming is harder (latency, time zones)
• Customer availability is harder (no walking over to ask)
• Collective ownership is harder (less organic knowledge spread)
• Trust is harder (less face time, less rapport)

If your distributed team has:

• Async-heavy culture (days between responses)
• Time zone gaps that prevent overlap
• Reluctance to use video or synchronous communication
• No established trust between team members

...XP practices will struggle.

Making it work requires:

• Overlapping work hours (at least a few hours per day)
• Strong written communication norms
• Deliberate relationship-building
• Tools that enable real-time collaboration

Some distributed teams do XP very well. Others can't make it work. The difference is usually communication culture, not geography.

Industries like healthcare, finance, and aviation have regulatory requirements that can conflict with XP practices.

Tensions:

• Continuous deployment vs. change control boards
• Collective ownership vs. individual sign-off requirements
• Simple documentation vs. compliance evidence
• Refactoring vs. re-validation requirements

However: XP isn't impossible in regulated environments. Many regulated teams use XP successfully.

Adaptations:

• Tests become compliance evidence (every behavior is validated)
• Change control applies to releases, not commits
• Documentation is automated from code and tests
• Risk-based validation (not all code requires the same rigor)

The key insight: XP's quality practices often exceed regulatory minimums. Comprehensive tests, code review (pairing), and traceability are things regulators want.

What XP resists is waste: documentation for its own sake, long approval cycles, ceremony that doesn't improve quality.

XP's engineering practices are non-negotiable. If the team refuses to adopt them, XP doesn't work.

Common resistance:

• "TDD is too slow" (misconception about productivity)
• "We don't have time to pair" (false economy)
• "Refactoring is gold-plating" (confusion about maintenance)
• "CI is overhead" (failure to see the value)

If resistance is from developers:

• It may be lack of experience (they don't know how)
• It may be past trauma (bad implementation they've seen)
• It may be identity threat (challenges to their expertise)
• Start small, demonstrate value, build skills gradually

If resistance is from management:

• "Pairing means half productivity" (educate on quality benefits)
• "TDD is wasted time" (show bug reduction, faster debugging)
• "We can't afford the investment" (show long-term cost savings)

XP requires buy-in. You can introduce practices gradually, but if the team or organization refuses to engage with technical excellence, XP won't take hold.

Some domains make TDD significantly harder:

UI-heavy applications: Testing visual appearance and interaction can be tricky. (Though modern tools like React Testing Library have improved this.)

Machine learning models: Testing probabilistic outcomes doesn't fit the assert-equals model.

Hardware-dependent systems: Physical device behavior is hard to simulate.

Highly concurrent systems: Timing-dependent behavior is hard to test deterministically.

For these domains:

• TDD may apply to parts of the system (business logic) but not others (UI, ML training)
• Different testing strategies may be needed (property-based testing, visual regression, hardware simulation)
• The principle (fast feedback on correctness) remains even if the practice adapts

Don't use these as excuses to skip testing entirely. Every system has testable parts. Push TDD as far as it can go; adapt where you must.