The GDM-Agile Paradox: Tips to Tap into the of Agile in the Global Delivery Model(リンク)という記事でAjay Bhandari氏とKumarasivan Veeramuthumoni氏は、オフショアモデルでアジャイル開発を行った際に彼らのチームが経験したことを報告している。彼らは自分たちの成功の要因をいくつか挙げているが、その一つは次のものである：
私たちに味方した２つ目の要因は才能ある人でした。私たちには、私たちが「銀の銃弾」と呼ぶ、無限の設計能力を持つ何でもするプログラマがいたのです。当然ながら、全てのチームに運良く花形プログラマがいるわけではありませんが、みなさんの才能がプロジェクトの要件にあうようにする方法はあります。
彼らは、この技術的なヒーローが成功のために絶対に必要だった理由の詳細について述べるとともに、もしこのレベルの専門知識がないのであれば、オフショアモデルでアジャイルを推進しないように、アドバイスしている：
一般的な経験則として、プロジェクトが示す技術的な内容が多いほど、アジャイル開発を用いることは難しくなるでしょう。なぜでしょうか？技術的な内容がもっと多いということは、もっと複雑であることを意味しています。例として、私たちのプロジェクトを見てみましょう。私たちがWebサイトに取り入れることを計画した多くの機能では最先端の技術が必要となりましたが、大部分は、私たちのチームにはほとんど経験が無いものでした。私たちにとって幸運なことに、私たちの「銀の銃弾」は、素早く新しい技術への理解を深め、コードを試し、チームの残りのメンバがまねることの出来る理想的なプロセスを開発することが出来ました。彼の能力がなければ私たちのチームには歯が立たず、アジャイル開発が奨励する素早い決断をすることが出来なかったでしょう。私たちは多くのプロジェクトが技術的な内容の過多のために終了したのを見てきました。こうした状況では、もしみなさんがアーキテクトを経験していないなら、アジャイルを用いないで下さい！
このアドバイスは著者らが苦労して得たもので、彼ら自身の経験に基づいている。しかし、これはアジャイルの主流のアドバイスとはかみ合わない：
- Book Review: The Responsibility Virus Helps Fear Undermine Collaboration(参考記事・英語)では、ヒーローは燃え尽きをもたらす極限状態と考えられており、支持できない。
- Noted Professor Decries "Macro Management"(参考記事・英語)では、ヒーロー的なリーダーシップはビジネスに蔓延する問題であると見られている。
- Kent Beck: Be Yourself - Create More Value(参考記事・英語)では
Beck氏は、彼が「天才的嫌なやつのジェットコースター」と呼ぶ、私達に仕事でヒーローになるか...あるいは愚か者になることを要求するパターンから降りることを検討しているが、私達がヒーローのはずがないからである。彼のアドバイス：仕事中はいつもの自分でいてください。
さて、分散アジャイル開発は違うのだろうか？ヒーローは従うべきパターンだろうか、あるいは避けたほうがよさそうだろうか？