アジャイルを採用している組織は，時として，期待したメリットが得られないことに不満を訴える場合がある。考えられる理由のひとつは，アジャイルの価値観と原則を支える技術的なプラクティスの実践に対して，十分に注意を払っていないことだ。
"The State of Agile Software Development"と題したブログ記事でMatt Badgley氏が述べた意見が，アジャイルコミュニティの中に，エンタープライズアジャイルとスケーリングアジャイルに関する議論を引き起こしている。
企業組織にとって，エンタープライズアジリティへの対応 - ビジネスあるいは市場の変化に対する，迅速かつ効果的な適応能力が必須であるというのは，衆目の一致するところです。エンタープライズアジリティのニーズを満たす- そのために大企業は，ソフトウェア開発や他の部門へのアジャイルプロセス採用を推進しています。エンタープライズアジャイルのニーズへの対処を目的として，数多くのフレームワークやアプローチが出現しました。この流れの一部として，フレームワークの実装を支援するコンサルタント経済が形成されています。このような状況を，アジャイルソフトウェア開発の純粋主義者たちは不快に感じているのです。懸念されるのは，コンサルタントやフレームワークが実現しているものが，中間管理層やPMOに対して，彼らが常日頃から望んでいるもの – 単に"アジャイル"ということばを入れただけの，ヘビーウェイトでコントロール指向の認定プロセス – の提供に過ぎないという点です。これはまさに，アジャイル憲章を書いた初期のアナキストたちが変えたいと思っていたものなのです。
氏はイノベーション適応ライフサイクルの視点から，アジャイルはキャズム(chasm)を越えて，今はイノベーションの不連続点にあるのだろう，と説明する。アジャイルの命脈が尽きて何か他のものに置き換わるのかも知れないし，あるいは，アジャイル憲章の価値観と原則を適用することで獲得できる，望ましい結果に基づいて続いていくかも知れない。
私たちはアジャイルエンジニアリングの優れたプラクティスを継続し，クラフトマンシップの考えを持ち続けなくてはなりません - これがなくては，アジリティは成り立たないのです。透明性の徹底が必要です。それなくして信頼はあり得ません。幹部や経営ランクの関与も必要です – 教育では不十分です。さらに私たちは，いつでも人を最も優先しなければなりません。事をなすのは人であって，プロセスではないからです。そして最後に，Dave Thomas氏がブログで指摘するように，私たちはすべてにおいてアジリティの中心 – 今いる場所を判断し，目標に向かって小さな一歩を踏み出し，学習に基づいて補正する，これを繰り返す – に立ち返って，判断と変化，そのすべてを容易に行えるようにしなければならないのです。
Calen Legaspi氏は，アジャイルの神話についてブログしている。その"agile myth #1: agile is a methodology"の中で氏は， アジャイルがプロセスではないことを明確にする。アジャイルは"ソフトウェア開発プロセスを成功に導くための価値と原則"に関するものであって，プラクティスの使用に基づく技術的な卓越性は，その中のひとつなのだ。
アジャイル憲章の17人の著者の多くは，ソフトウェア開発の技術面における思想的リーダです。Kent Beck氏はJUnitとテスト駆動開発の作者ですし，Martin Fowler氏はデザインパターンやリファクタリングに関する書籍をいくつも著しています。Robert Martin氏にはオブジェクト指向設計やコード品質に関して，いくつかの著書があります ... アジャイルは主としてプロジェクト管理を扱うものと考える人が多いのですが，アジャイルのクリエータたちは，それ以上とは言わなくても，それと同じ程度の重点をエンジニアリングに置いているのです。
Robert Martin氏は，"The True Corruption of Agile"というブログ記事で，アジャイルの文化や価値観，プラクティスについて語っている。"文化は価値の表現"であり，"実践するプラクティスは文化の発現"である，と氏は言う。
継続的インテグレーションや短期間のイテレーション，ペアプログラミング，テスト駆動開発などを実践するチームに所属しているのならば，それはあなたが，アジャイル憲章と価値観を共有するチームにいるという，何よりの証明です。価値観を共有しないのなら，そのようなプラクティスに従うはずもありません。
一種の儀式尊重主義(Ritualism)によって，価値を理解することなく，プラクティスに従う場合もある。
チームがプラクティスにとらわれ過ぎるあまり，次第にプラクティスの表現する価値観のことを忘れてしまう場合があります。官僚や宗教によくある失敗です。プラクティスがあまりに強く定義されたために，そのプラクティスが決まり事になり，元々の価値観が失われ，決まり事が価値観になってしまうのです。
アジャイルの失敗は，技術的なプラクティスの欠如に起因する場合もある，と氏はいう。
アジャイルムーブメントにおいて最大の問題は，プラクティスの排除です。ひとつひとつ年を追うごとに，プラクティスは重要視されなくなるか，あるいは取り除かれていきます。このようなプラクティスの喪失はアジャイル文化を希薄化して，もはやアジャイルとは認められない何かに変えていきます。卓越性への道を大きく逸れて平凡なものへと向かい，厳しい現実を避けて，耳当たりのよい決まり文句へと進んでいくのです。
プラクティスの喪失は，技術者にアジャイルへの移行を放棄させる一方で，同時にマネージャは，アジャイルを単なるソリューションとして適用しようとする。その結果，開発者とマネージャの溝はさらに深まるのだ。
ソフトウェアクラフトマンシップ運動は，アジャイルを成功させる上での技術的プラクティスの重要性を強調することによって，プラクティスと文化と結合を維持しようとするものだ。
XPのオリジナルの13プラクティスは聖書なのでしょうか？ TDDを実践しない者は背信者なのですか？当然ながら，そんなことはありません。ですが，もしこれら特別なプラクティスを使っていないのなら，今以上の結果を得るために，いくつか使ってみてもよいと思います。それらのプラクティスが文化を定義し，自分たちの価値観を表現してくれることでしょう。
あなたの価値観がアジャイル憲章のそれならば，あなたのプラクティスは，オリジナルの13憲章に極めて近いものになるでしょう。大部分において，これら13のプラクティスが憲章を書く動機となったのですから。
InfoQでは今年の初め，Tim Ottinger，Ruud Wijnands両氏にインタビューして，アジャイル適用に際して組織が直面する問題への見解を聞いている。アジャイルの復権に関するQ&Aの中で両氏は，アジャイルにおいて技術的プラクティスが重要と考える理由を説明してくれた。
Tim: 技術的なプラクティスは，コードを常に動作可能な状態にすることで，頻繁なリリースを可能にします。そのようなプラクティスをまったく用いない企業もありますが，コードベースを管理せずに頻繁なリリースをしようとするために，彼らのコードは粗雑なものになっています。それでも彼らは，新しいプロセスを遵守して，それに従うのです。プログラマやテスタにとっては面白くない状況ですし，開発速度が落ちるのを見てハッピーな人は誰もいないにも関わらず，マネージャは技術的プラクティスの適用を認めようとしません。彼らは，ペアプログラミングやペアテスティングが不効率なのではないか，と恐れているのです。自分たちのマイクロマネジメントが技術的なプラクティスの採用を妨げているのではない，と考えているのです。
Ruud: (…) 私の見る限り，アジャイル採用に成功している企業は，例外なく技術的プラクティスの価値を認め，実行しています。あまり成功していない企業では，そうではありません。
ブログ記事 "behavioral traceability: values to principles to practices” の中でGeof Lory氏は，価値観と原則，プラクティスの関係を可視化するためのソリューションを提供する。このソリューションは，すべての価値がプラクティスに含まれていることや，プラクティスを実践する人たちがその基本にある原則や価値を理解していることの確証を得るために有効だ。
プラクティスに盲目的に従うだけで，その根本にある原則を導き出そうとしていないのであれば，すべてのメリットは束の間の成果であって，持続することはないでしょう。問題なのは，プラクティスの実践それ自体が，その基本にある原則を保証するのではない，ということです。プラクティスそのものに意味があるのではありません。本当に重要なのは，その背後にある原則なのです。
氏が勧めるのは，要件のトレーサビリティと同じような方法で，トレーサビリティを適用することだ。そのためには，氏がインテント(intent，意図)と呼ぶものを使用する。
インテントとは，プラクティスと原則，原則と価値を結びつける糸です。意図(インテント)を理解することで，自分たちがその原則と価値に沿って生きているかどうか，自らを欺くことを防ぎます。このインテントとアライメントを明確化するメカニズムが"Team Operating Agreement"なのです。
プロジェクトを開始する前には，チームの運営に関する合意(Team Operating Agreement)を確立しておくことが必要だ，と氏はいう。
Team Operating Agreementは，チームメンバが自分自身と他のメンバに対して責任を持つ上で，明示的に合意し，意図している価値観や原則，プラクティスについて，その概要を示すものです。このドキュメントは時間とともに変化し，最終的には，私が"チーム文化"と定義するもの，すなわち，多くの人たちが時間の大部分を費やして行っている(あるいは少なくとも，行おうとしている)ことを表すものになります。
アジャイルを採用する場合，プラクティスはチームのニーズに応じて選択すればよい。ただし，アジャイルへの変革を継続的なものとするためには，その基礎となる，組織におけるアジャイル変革の原則や価値観に沿うことが必要だ。
どのような行動の変化でも，人はまず実践によって学び，その後で背景にある原則や価値観との関連を会得するものです。この関連がなければ，行動の変化が自立的に維持されることはありません。また，内部との整合が取れないプラクティスは，コンプライアンスを確保するために外部の第三者によって監視される必要があります。このような外部ガバナンスプロセスは現状を維持するように設計されていますから，プラクティスは状況や環境の変化に遅れを取ることになります。従来のプロセス偏重の方法論は，この状況をよく表しています。
しかしながら，他でうまく行っているいくつかのプラクティスを，何も考えず単にまねするようなことはできません。組織やチームはそれぞれ違うのです。アジャイルの価値観や原則を理解しない限り，チームに固有の状況に合うプラクティスの適用に苦労することになるでしょう。アジャイルのメリットのほとんどは，そのような相違に関わらず，チームが効果的かつ効率的に作業できることから来ています。アジャイルには適応性があるのです。