ブロガ，コンサルタント，そして著作者でもあるJonathan Kohl氏は，今日のチームが開発作業を行う技術的環境が，一般的な開発プロセスの大部分が定義された頃とはまったく違っている，と指摘した上で，チームが自分たちのプロセスを意識的かつ積極的に検討して，今日の開発の現実に自ら適用させていくように促している。
氏は先日，Better Software誌に "物事は変わる (プロセスもそうあるべき)" と題する記事を公開した。その中で例として取り上げたのは，モバイルデバイスにおける自動テストの利用だ。
自動化されたユニットテストは，アジャイル開発プラクティスの中にあって，広く受け入れられているもののひとつです。私たちは過去15年間，この分野において，ユニットテストツールやフレームワーク，プラクティス，そして体系的ノウハウが急速に拡大するのを目の当たりにしてきました。それに加わることがエキサイティングだったのです。しかしモバイル開発のフレームワークでは，自動ユニットテストのサポートがまったく不十分な場合があります。Webなど従来のテクノロジで，この種のツールを使うことのメリットに慣れていると，これが不安の原因になります。モバイルデバイスでは，状態(state) – 無線の条件，デバイスに内蔵されたセンサの動作と最適化，ユーザ操作，感性と知覚，さらには天候の変化や照明など – が非常に重要なのですが，自動ユニットテストがこのような問題にまったく対応できていないことは明らかです。ですから，モバイル開発者である私の友人たちは，自動ユニットテストをほとんど利用しません。別の品質的なプラクティスで，その大部分を代用しようとしているのです。
氏はその時々の必要に応じて，さまざまなテクニックを注意深く適用することを提唱すると同時に，チームに対しては，選択したアプローチの"ルール"の外に目を向けることも必要だとして，次のように述べている。
アジャイルコーチをしている友人の中には，モバイル開発チームがユニットテストをほとんど使わないことに愕然としてしまう人もいます。しかし彼らは単に，エンドユーザの要求する品質基準に対して，もっと適した別のスイートを見つけただけなのです。モバイルチームもほとんどは，最初のうちは標準的な開発プロセスやツールを使うのですが，特定分野でのサポートのギャップや不足に気付いて，別のプロセスを選択することになるのです。
Laurant Bossavit氏は，"現地踏査(Ground Truths)" の結果でソフトウェアエンジニアリングを懐疑的に見る書籍 "The Leprechauns of Software Engineering" の著者である。氏は先日，Google+のスレッドで，プロセスやアプローチに対する建前だけの遵守について，同じような主張をしている。氏は今日のチームに見られる行動の多くを，OOを採用した組織にかって数多く見られた行動と対比しながら，次のように述べている：
"どんなアジャイルプロセスであっても，耳をふさいで舞台裏に一日中隠れていられる" というのは，"どんなOO言語でも，手続き的コードを書くことができる" ということの今日的表現です。
次に氏は，現場の最前線でアジャイルがどのように使われているかを論じる。
ずっと昔，アジャイルが最先端だった頃，アジャイルに関心のある人に会ったならば，彼らは確実に好奇心と意欲に満ちて，スマートな，一言でいえば例外的存在だったはずです。非の打ち所がなかったとか，どこでも当然のごとく高給を得ていた訳ではありませんが，少なくとも群衆から頭ひとつ抜きん出た存在であったことは確かです。
しかし今日の現実では，
アジャイルはもはや，大して"最先端"ではありません。もしあなたが，傑出した人物との出会いを求めてアジャイルに関心を持ったのだとすれば，その目的には何か別のものを探すべきだ，と確信を持って言えます。
氏はアジャイル自体の放棄を提唱しているのではない。そのアプローチから最大限のメリットを引き出すためには，時間と努力が必要だ，と主張しているのだ。これには労力と，慎重な検討が伴う。
同じように，偽陽性 – わずかな実体験や願望をもとに "アジャイル" を実践していると主張する人々 – が多すぎるからと言って，そのラベルが無意味だということにはなりません。表面的なものの下を見るべきだ，ということです。安価でない，簡単には模倣できないような価値あるものを見つけるのです。同じように，アジャイル放棄を声高に喧伝する人たちの間でも，大部分は必然的に似たようなことになるでしょう - 時宜を得て変わるという昔からのやり方で，コストの所有ではなく，色鮮やかに印された本質的属性よってのみ実践されるのです。
記事の結論には，次のように述べられている。
あるプロセスを実施していて，最初の成功の後，品質の問題を発見したり，誰かがプロセスに乗り遅れたり，定常的に遅延や予算超過が発生したりすると，自分自身に問題があるように考えがちです。誰かを責めるのではなく、プロセスを確認してみましょう。 もはや適切ではないのかもしれません。 そのプロセスは，チームが価値を創造するために役に立っているでしょうか，あるいは障害となっているのでしょうか？ 同時に私たちには，ユーザやプロジェクトの利害関係者，企業のオーナといった人々のためだけではなく，チームメイトや私たち自身のために，価値を創造する必要があることも覚えておいてください。これらの領域のいずれかにおいて，積極的に価値が創出されていないならば，問題があると言えるのです。