XP’s practices are valuable, but the framework was explicitly designed for environments where working software can be deployed continuously and requirements evolve from user feedback — neither holds for aircraft flight control software.

Team size is a structural constraint, not a coordination problem solvable with one practice. XP’s collective ownership and verbal coordination break down well before 200 people. Frameworks like SAFe or LeSS exist because XP doesn’t scale this way.

Swapping practices doesn’t address the domain mismatch. The issue is XP’s continuous-delivery and rapid-iteration assumption, which is invalid in safety-critical aerospace, regardless of how testing is done.

Frequent merging without fast feedback gives you the cost of frequent integration (more merge resolutions, more in-flight changes) without the benefit (fast detection of problems). Frequency without feedback speed misses the point.

Test count is one input to build time, but the benchmark is on the output (10 minutes) because that’s what the feedback loop bottleneck is. A team can have many fast tests and a fast build, or few slow tests and a slow build — what matters is wall-clock feedback.

The directionality is reversed. XP wants builds faster, not slower. Slower builds are a problem, not a thoroughness signal.

Bus factor (the number of people who can be hit by a bus before the project stalls) directly measures key-person risk. Collective ownership distributes knowledge so no single departure cripples the project.

Without collective ownership, fixes require finding the module owner, scheduling their time, and waiting. With it, any developer can ship a fix in their flow. This is one of the practice’s headline operational benefits.

When reviewers have touched the code before, they understand it, review faster, and catch real issues instead of surface formatting. The practice creates a virtuous cycle: more familiar code → faster review → more shipped → more familiar code.

XP explicitly requires coding standards to make collective ownership work — without unified style, every file looks different and reviewers waste effort on superficial inconsistencies. The two practices reinforce each other; standards don’t disappear with collective ownership, they become more necessary.

Silos = key-person dependencies = bottlenecks. Collective ownership directly attacks this failure mode by making knowledge of any module a team property.

Averaging discards the information that the divergence carries — namely, that the two developers see different problems. Resolving by arithmetic skips the conversation that would surface the hidden complexity.

Voting hides whichever party has the relevant information from the team. If the 13-point estimate reflects a real hidden risk, voting to dismiss it produces an under-scoped story that explodes mid-iteration.

Seniority is not a substitute for the information held by the divergent estimators. The senior developer may not know about the new library or the hidden migration; the conversation surfaces both.

“Costs even out automatically” is a faith-based answer; the actual evidence is that pair programming has measurable defect-rate and knowledge-distribution effects that change the calculus. Without naming those, you’ve conceded the cost objection.

Morale is a real secondary benefit, but framing it as the primary defense concedes the engineering argument — which is where the strongest case sits. Pair programming has measurable defect-rate and design-quality effects; lead with those.

Junior developers often benefit most from pair programming because they learn through navigated practice with a senior. Excluding them forfeits one of the practice’s strongest applications.

TDD demonstrably improves test coverage, defect rates, and design pressure. The criticism here is real, but it points at TDD’s blind spot, not its fundamental brokenness. Abandoning it would lose the benefits and not fix the structural problem.

Writing tests after the code loses TDD’s design-pressure benefit (small classes, dependency injection, clear interfaces all emerge because the test was written first). It also doesn’t address the structural-debt root cause.

TDD works in every paradigm. Successful TDD codebases exist in Java, Python, Ruby, Haskell, C, and embedded firmware. Language is unrelated.

XP is explicit that its practices are loosely coupled and teams adapt them to context. The defense isn’t that they’re all mandatory — it’s that they reinforce each other in ways that matter.

TDD’s productivity benefit depends heavily on the surrounding practices (small releases for feedback, refactoring discipline, paired knowledge transfer). Isolating TDD discards much of its leverage.

Scrum and XP can coexist — many teams use Scrum’s planning ceremonies plus XP’s engineering practices. Recommending Scrum as a substitute for XP misses that XP’s engineering discipline isn’t part of Scrum at all.

Conflating them mixes business-level prioritization with technical-task breakdown — the customer ends up debating implementation details, and developers end up debating which features matter. Separation lets each conversation happen at its right level.

Both meetings are XP practices. Release planning is the longer-horizon planning game; iteration planning is the per-iteration planning game. Waterfall has different planning structures, often a single big up-front plan.

Daily standups are short coordination meetings (~15 min) during the iteration. Iteration planning is a longer up-front meeting that scopes the whole iteration’s work.

TDD isn’t the problem; incomplete TDD is. Stopping it would lose the GREEN+RED design pressure without fixing the REFACTOR omission.

Tests cannot diagnose design problems — they verify behavior, not structure. Adding more tests against bad structure pins the bad structure in place by making it harder to change.

Manager review is too late and too coarse. The point of REFACTOR is to clean immediately after the test passes, while the code is fresh — not days later when the developer has moved on.

Documentation has its place but does not directly address whether to discard or continue the flawed work. The Agile Manifesto explicitly devalues comprehensive documentation as a primary value.

Rigid adherence to commitment is the Waterfall value XP exists to reject. The whole point of iterations is that committing to a course of action is cheap enough to walk back when the iteration reveals it’s wrong.

Customer collaboration over contract negotiation is the relevant Agile value here — and even that doesn’t force the team to deliver flawed work. The customer would prefer a working product over a broken one delivered exactly as initially specified.