彼らの主張は、関係が生まれる前に変更される可能性のある将来の要件に投資しないという利点によって、これは十分に補償されるということだ。
将来の不確実な要件を考慮してコーディングや設計をすることは、必要ではないかもしれないものにリソースを費やすリスクを意味し、重要な機能を遅らせてしまう可能性がある。
「コミュニケーション」の価値に関連して、設計とコーディングのシンプルさは、コミュニケーションの質を向上させるはずである。
非常にシンプルなコードによるシンプルな設計は、チーム内のほとんどのプログラマーが簡単に理解できる。
フィードバック.
エクストリーム・プログラミングでは、フィードバックはシステム開発のさまざまな側面に関連している:
フィードバックは、コミュニケーションとシンプルさに密接に関係している。
システムの欠陥は、特定のコードが壊れることを証明するユニットテストを書くことで簡単に伝達される。
システムからの直接のフィードバックは、プログラマーにこの部分を再コーディングするように伝える。
ケント・ベックを引用すると、「楽観主義はプログラミングの職業上の危険である。フィードバックが治療法である。」
勇気.
いくつかのプラクティスは勇気を体現している。
これは、設計の行き詰まりを避け、余計なものを実装するために費やす多くの労力を回避するための取り組みである。
勇気により、開発者は必要に応じてコードのリファクタリングを快適に行える。
つまり、既存のシステムを見直し、将来の変更をより簡単に実装できるようにする。
勇気のもう一つの例は、コードを捨てるタイミングを知ることだ: そのソースコードを作成するためにどれだけの労力が費やされていたとしても、陳腐化したソースコードを削除する勇気である。 
また、勇気とは永続性を意味する: 
プログラマーは複雑な問題に一日中悩まされても、翌日にはすぐに問題を解決しているかもしれない。だが、それは永続性がある場合に限られる。
リスペクト.
リスペクトの価値には、自尊心だけでなく、他者への尊敬も含まれる。
プログラマは、コンパイルを中断させたり、既存のユニットテストを失敗させたり、仲間の作業を遅らせたりするような変更をコミットしてはならない。