たくさんの解説者がアジャイル導入のよくある誤りとアンチパターンについて書いてきた。彼らはさまざまな組織におけるアジャイル導入の誤りを避けるためにすべきこと「トップX」を投稿している。
Target ProcessのMichael Dubakov氏は、“10 Most Common Mistakes in Agile Adoption” (Part 1 & Part 2) という2つのブログ記事を書いた。彼は「企業はアジャイル導入において何度も同じ間違いをしている」と主張している。
彼が挙げたよくある誤りは以下の通りだ。
1. ツールから始める
アジャイル開発はそうではない。ツールは即座に効果が現れるものではなく、ツールがあっても問題はほとんど解決しない。さらには、より重要な目標に目をつぶって、あなたはツールの導入に励んでしまう。
2. プロセスから始める
ほとんどの企業はプロセスから始める。これはあまり深刻ではないが、よくある誤りだ。あなたはスクラムに関する本を読む。最初のうちは簡単に見えてしまう。あなたはスクラムプラクティスをすべて適用する。数スプリント後、開発は多少改善されたように思えるのだが、期待したほど劇的ではない。やがて興奮は冷めやり、プロセスの価値は低下する。プロセスを試す前にどんな企業も最初にすべきことは、コミュニケーション、コラボレーション、フィードバック、信頼、情熱といったアジャイルの価値に注力することだ。こうした価値を低く見ているのなら、すぐれた開発プロセスを適用するのはほぼ不可能だ。
3. 開発プラクティスは十分だ
興味深いことに、開発者はTDD、継続的インテグレーション、ペアプログラミングといった技術的プラクティスを適用する傾向があるが、コミュニケーション、一体化したチーム、オンサイトに顧客がいること、ふりかえりなどには、あまり注意を払っていない。
4. スクラムは十分だ
本当に間違っているのは、単にすべての問題を解決するプロセスとして、スクラムに頼ることだろう。スクラムは頼りになるが、ペアプログラミングからBDDまで、いろいろなことを受け入れて試すことに前向きである場合に限られる。最もすぐれたコーチであれば、スクラムはXPの技術的プラクティスと密接に関連して導入されるべきだと信じている。
5. CSMはすべてを知っている
認定スクラムマスター(Certified Scrum Master)は神様ではない。確かに、彼にはスクラムに関する基礎知識がある。しかし、たいていの場合、それだけだ。
6. CSTはすべてを知っている
認定スクラムトレーナー(Certified Scrum Trainer)は神様ではない。確かに、彼はたくさんのことを知っていて、経験も相当ある。彼はアジャイル導入を支援できる人物である可能性は高いが、支援するだけだ。彼はあなたのドメインについて、あなたの特殊事情について、あなたの組織の根本的原因について、何も知らないだろう。単純にCST任せにして、アジャイル導入を彼に委ねてしまうと、失敗に終わるだろう。
7. 機能的部門は残すべきだ
機能的部門や機能的チームを維持すべき絶対的な理由はない。可能であればいつも、チームとして一緒に仕事をするべきだ。もちろん、米国にテスターがいて、インドに開発者がいる場合にはほとんど不可能かもしれない。しかし、全員が同じビルに席があるのに機能横断チームがないのは、ただ愚かなだけだ。
8. 顧客のフィードバックがなくても生きていける
アジャイルはたいてい、素早いフィードバックを必要としている。顧客からのフィードバックは最重要だ。もしあなたが間違ったやり方でものを作っていれば、それはまずいことだ。しかし、もしあなたが間違ったものを作っていれば、それは本当にひどいことだ。なぜかって？ あなたは後でそれを投げ捨てなければならない。顧客からの定期的な（かつ、素早い！）フィードバックは、岩礁のある港での航海指示のようなものだ。風の変化やその他要因に基づいて、進路を常に補正しなくてはならない。顧客は最も価値のあるチームメンバーであり、しかるべく扱われなくてはならない。
9. 自己組織化は簡単だ
純粋な自己組織化とはリーダーが現れることを想定している。それは頻繁に起こるものではない。多くの場合、リーダーがいないとチームの成長は止まり、平凡な状態をさまよう。リーダーはビジョンを設定して、チームを正しい方向へと推し進める。リーダーは信頼、情熱、内省に力を与える。これが最終的に自己組織化へとつながる。
リーダーがチームから離れると何が起こるのだろうか？ たいていの場合、ゆっくりと後退したり、悪化していくだろう。これは自己組織化が失われたという明確なサインだ。真の自己組織化されたチームは、リーダーがいなくてもその価値と進捗を維持するだろう。
10. 間違った目標（例えば、顧客がアジャイルにやるよう頼んだ）
もしプロジェクトにアジャイルプロセスを要求する顧客がいるのであれば、神様に感謝しなくてはならない。この機会をアジャイル導入の転機として活用しよう。
残念なことに、多くの企業が契約を取り付けようと、アジャイル導入の「まねごと」をやろうとしている。彼らはCSMコースに人員を派遣し、アジャイルプロジェクトマネジメントツールを購入し、スクラムを表面的に適用する。彼らは意味深い目的や企業風土の変革なしに、すべてをやろうとする。彼らは情熱なしにすべてをやろうとする。
ブログLeading AnswersのMike Griffiths氏は“Agile Adoption Anti-Patterns”について書き、これまでに見てきた5つのよくある誤りを挙げた。
1. 銀の弾丸としてのアジャイル – 確かに、アジャイルメソッドを使うと時間を節約でき、ビジネス理解を高め、高品質な製品を生み出せる。しかし、これは銀の弾丸ではない。空間や時間を曲げるわけではなく、限られた時間と予算とリソースの制約内で、できるだけ多くの成果を届けることを可能にするものだ。
2. 規律のない口実としてのアジャイル – 誰かの信念には反するが、アジャイルメソッドは規律を放棄しておらず、計画や見積りの必要なしにコーディングに突入するわけではない。アジャイルメソッドはテスト駆動開発、Wideband Delphi法による見積り、2週毎のイテレーション計画といった、数々の高度な規律あるアクティビティやテクニックを必要とし、見積りセッションには多くの自制を要する。
3. 説明のないアジャイル – プロジェクトとチームは真空の中では生きていけない。彼らには、組織のたくさんのステークホルダーとのやり取りがある。最初にアジャイルプラクティスをあなたのチーム、あなたが影響を及ぼすドメインに植え付けるのは簡単に思えるかもしれないが、うまくいっているプラクティスを他人に説明しなくてはならないときがやってくる。
4. 浅いフィードバック – 理解を確認して完了した仕事を認めてもらうのに、アジャイルメソッドは進化していくシステムにおけるフィードバックを頼りにしている。通常、新しい機能は経営陣にデモされ、トライアルとフィードバックのためのテスト環境におかれる。もしほとんど、あるいは、まったくフィードバックがないと、ユーザは開発したものに満足しているに違いないと考えてしまいがちだ。しかし、実際には適切に調べていなかったり、実際のデータやシナリオを使って適切に試していない場合がほとんどだ。
5. アジャイルプロセスへの執着 – みんながこれは一般的に良いものだとアジャイルメソッドに夢中になっている。しかし、ビジネス価値を届けるのを犠牲にして、そのプロセスに注力しすぎてしまうと問題だ。プロジェクトは通常、ビジネス変化やビジネス改善をもたらすために始められて、資金がつぎ込まれる。私たちは完全なメソッドを実践するためにビジネスをやっているわけではない。最終的な目標はスポンサーとユーザを喜ばせることであり、プロセスに執着したり、レジュメを作ることではない。
Craig Larman氏とBas Vode氏は“Top Ten Organizational Impediments to Large-Scale Agile Adoption”という記事を書いた。その中で、彼らは「大企業で/と仕事をしているアジャイル開発のエキスパートたちに、最大の課題となっている組織障害について質問した」。
そのトップ10には以下が含まれている。
10. スクラムの共同創始者であるJeff Sutherland氏は、組織障害の除去の失敗を大企業における主たる障害だと考えている。
9. 経験ある開発マネージャで、Xeroxでリーン原則の導入に関わったPeter Alfvin氏と、Reaktor Innovationsでアジャイルコーチング部門の責任者であるPetri Haapio氏はともに、局所最適につながるコスト「削減」と「相乗効果」を求める中央集権型の部門が障害だと述べた。
8. Nokia Siemens Networksでアジャイル開発活動のグローバルコーディネータであるSami Lilja氏は、学習を時間とお金の無駄だと見なしている組織があると注意した。
7. Ericsson上海の専門家であるLarry Cai氏は、機能的組織（単一機能のグループ）が最大の障害のひとつだと述べた。それらはコミュニケーションの壁を作り、部門間の責任のなすりつけ合いを助長する。
6. コンサルタントで熟練したファシリエーターであり、組織的学習ついての本を2冊書いているEsther Derby氏は、全体最適よりも局所最適を助長するシステムが主要な障壁だと考えている。彼女は目標管理(MBO)や予算システムなど、いくつか例を挙げた。
5. Siemens Medical Systemsで以前アジャイルコーチをしていたMike Bria氏は、「日曜大工による家の修繕」が障害だと述べた。彼は本を1、2冊読んで「やり方は知っている」という態度が問題なのだと強調した。
4. 巨大なEコマースサイトのひとつでスクラムトレーナーをしているAさん（リクエストに応じて名前は削除した）は、個人のパフォーマンス評価と報酬が主たる障害だと述べた。それらは開発者やマネージャをイライラさせ、チームのパフォーマンスを妨げ、指揮統制マネジメントを助長する。
3. スクラムトレーナーであり、杭州にあるNokia Siemens Networksで大きな開発グループの部門マネージャをしているLü Yi氏は、「コミットメントゲーム」と非現実的な約束が大きな組織的障害であると考えている。これは手抜きや継続的な消火活動、レガシーコードへとつながる。
2. 熟練したファシリエーターであるDiana Larsen氏は、Agile Retrospectivesの著者であるEsther Derby氏とともに、「すべてが開発者の問題だと思い込むこと」だとシンプルに述べた。
1. ほとんど全員が「銀の弾丸という考え方と表面的な導入」を主たる障害として挙げていた。
他の人が挙げたポイントに加えて、Larman氏とVode氏は定期的に見られる障害をさらに2つ挙げた。
Craig氏は、実際のチームやチームワークよりも、個々のメンバーの考え方が大きな障害だと考えている。彼は表面上スクラムを導入している個人のグループをいろいろと訪問して、「チーム一体」、ペアプログラミング、グループ内マルチ学習に向けた動きではなく、「JillがJillのタスクをして、RajがRajのタスクをして」といった状況を見てきた。Bas氏はマネジメント職にいる人と現場で仕事をしている人との間のギャップが大きな障害だと考えている。マネジメントレベルでなされる変化は、どんなに実際に価値がある仕事であっても、影響を及ぼさない（あるいは、少なくとも良い影響はない）ことが多い。同様に、現場の開発者による判断は、組織の方針に沿っていないことが多い。
アジャイルテクニックを実践する上で、よくある誤りや問題とは何だろうか？ どうすればチームと組織はそれらを避けられるのだろうか？