失敗パターンを思いついた３つのポイントを書く。

アジャイル開発への知識不足

そもそも、この理由のケースがとても多い気がしている。
まとめページだけの知識で始めてしまう人が多い。もしくはトップダウンにより十分な知識が無いまま走り出してしまうケース。

名前しか変わらない開発プロセス

マネージャーの名前をスクラムマスタに変えただけで、マネジメント方法が変わらない。
進捗確認会議を振り返りと呼び、仕様変更の差し込み作業をアジャイルと呼ぶ。
既存のプロセスとは全く違うものなので、しっかりと知識を付けてから戦略を持って導入して欲しい。

勉強のためのステップ

１．書籍やWeb記事などで勉強する。 アジャイルの概念とアジャイルの手法の違いをしっかり理解して欲しい。
まずはスクラム、XP、リーンの手法などを勉強してみるのが良いと思う。

２．書籍にあるものは半分は理想論であり、基本でしかない理解する

３．勉強会などで生の声をスピーカーや参加者から聞く

伝え方と開発チーム準備

十分な知識があっても、開発は１人でやるものではない。
チームもまたそれなりにアジャイルの知識が必要になる。

基本をカスタマイズする

また、上記の２番で書いた通り、様々な手法はあくまで基本である。
チームにフィットする形に変えながら導入したり、手法の全てを一気に適応するのではなく、変化のコストが小さいプラクティスから導入するなどの戦略が必要である。

チームのアジャイルに対するモチベーションの向上 変化の喜びと向上の実感

誤解を与える形で知識を共有し開発が進められれば、アジャイル開発が成功するはずがない。
コストの小さなプラクティスで開発がうまくいっている実感があればチームメンバーもアジャイル開発に前向きになる。
まず導入するべきは偉い人が話し合う場ではなく、メンバ達の意見を吸い上げて実行する改善サイクルだ。
それはスタンドアップミーティングでも良いし、KPTでもよい。導入を目指す仮のスクラムマスタはそれを吸い上げて、しっかりフォローと実行をされるようにしよう。

最初が肝心

大岩を動かす時は最初の転がりだすまでが一番力が必要で、一度転がせば、その岩自身の重さで少しの力でどんどんと転がり進む事ができる。
自分がしっかりと得たアジャイルの知識を元に、なぜこういう方法になっているか？を丁寧に説明しながらチームにアジャイル精神を浸透させよう。

顧客を巻き込まない

もっとも変わる所はここである。
ウォーターフォールではプロセスの隣の関係者としか関わらないため接点を最小に出来るが、アジャイル開発では常にサイクルが重要であり、市場や状況の変化や開発現場で分かった新しいフィードバックを取り込んだ選択と決定が必要だ。

顧客の欲しいものを語るエバンジェリストや代弁者

顧客、もしくは顧客の声を代弁できるプロダクトオーナーが必要だ。
顧客自身でなくプロダクトオーナーが顧客の代わりをする時は御用聞きにならないようにしよう。
プロダクトオーナー自身が顧客の目指す概念を語れるようになるまで顧客の声を常に聞き、開発チームへは何(What)を作るかではなく、なぜ(Why)作るかを説明しながら、開発項目を決めよう。

変化が大きい中で従うべき指針

従うべきは仕様書ではなく、本当に実現したいことの願いだ。
市場も変わる、開発での問題も起きる、状況は常に変化する。
そのとき最も重視することは価値を届けることだ。
顧客の要望は状況によって変化することもある。

ただし、全ての要望を受け入れていてはいつまでも完成しない。
そのときの判断としては
変化があっても今作っているものに価値があるならデリバリーすれば良い。
価値が変わってしまったならシステムも変える必要がある。仕様書に従っても意味はない。
この判断が出来るようになるには顧客がどのようなものに価値を考えてシステムを欲しているかを十分理解する必要がある。

顧客を巻き込み、常に価値の判断の場に参加してもらうようにしよう。

まとめ

開発プロセスが始まれば、もっと細かな小さな失敗サイクルがある。
ドキュメントの管理や振り返りの方法、進捗管理の方法。
ほとんどのWebの記事は開発プロセスに入ってからの失敗方法しか書かれていないように思えた。

ほんとうの原因はアジャイル開発を導入する前にあると思う。
上記３つの失敗原因を変えれる組織になっていないならば、アジャイル開発の導入自体を検討し直したほうが良いと思う。

細かな開発プロセスのサイクルの中での気をつけるべき観点などはアドベントカレンダーの別の記事などを呼んでみて下さい。
他に、聞いてみたい観点などあればコメントなど下さい。

何かの参考になれば嬉しいです。