このようにして、開発者の変更がシステムのその他の部分で開発者がほとんどまたはまったく知らない障害を引き起こした場合、
自動化された全ユニットテストスイートはすぐに障害を明らかにし、その変更がシステムの他の部分と非互換であること、そしてその変更を削除するか修正する必要があることを開発者に警告する。
伝統的な開発手法では、自動化された包括的なユニットテストスイートがないため、開発者は無害であると思っていたコード変更がそのまま残され、統合テスト中でしか現れず、さらに悪いことに、本番環境でしか現れなかった;
また、統合テストの数週間前または数か月前からすべての開発者が行ったすべての変更の中から、どのコード修正が問題の原因となったのかを特定することは、大変な作業だった。
シンプルさを前提に.
これは、すべての問題を、あたかもその解決策が「非常にシンプルである」かのように扱うことだ。
伝統的なシステム開発手法では、将来を見据えた計画を立て、再利用性を考慮したコーディングを行うように言われてきたが、エクストリーム・プログラミングはこれらの考え方を否定する。
エクストリーム・プログラミングの支持者は、一度に大きな変更を加えてもうまくいかないと言う。
エクストリーム・プログラミングでは、漸進的な変更を適用する:
多くの小さな段階が作られると、顧客は開発プロセスと開発中のシステムをより詳細に制御できるようになる。
変化を受け入れる.
変化を受け入れるという原則は、変化に逆らうのではなく、変化を受け入れるということだ。
プラクティス.
物議を醸している側面.
XP のプラクティスは激しく議論されてきている。
エクストリーム・プログラミングの支持者は、オンサイト顧客に非公式に変更を要求することで、プロセスが柔軟になり、形式的なオーバーヘッドのコストを節約できると主張している。 
XPの批判者は、これがコストのかかる手直しや、以前に合意や資金提供されていた範囲を超えたプロジェクトのスコープ・クリープにつながる可能性があると主張している。
変更管理委員会は、プロジェクトの目的と複数のユーザー間の制約に潜在的な矛盾があることを示している。