我々アジャイル開発者は成功体験を語るのは好きだが、失敗についてはなかなか口を開こうとしない。Robin Dymond氏はそこに切り込み、「あるスクラムプロジェクトの失敗(リンク)」という記事を書いた。
Robin氏は、既存の内部プロセスを置き換えるべく、様々な期待を背負っていたプロジェクトの記録を残した。
- 市販のソフトウェアを基盤にした実装
- 既存の業務プロセスについて深い経験を持つプロダクトオーナー
- 業務知識とアジャイル(成功)経験を持つチームメンバー
- かつてこの組織で広範囲にわたって働いたことがある経験豊富なアジャイル開発のコーチ
- ビッグ3コンサルティングファームは製品に関する知識をチームメンバーに提供した
2回目のイテレーションの終わり頃から雲行きが怪しくなっていった。プロダクトオーナーは、使っている市販のツールがタスクに適しているのかどうかを疑問に感じ始めていた。(3回目のイテレーションで)業務を行っているユーザに開発中のソフトウェアを試用してもらったが、ユーザからのフィードバックは例外なく否定的なものだった。そして、プロダクトオーナーは、先見の明が無かったとしてプロジェクトを外されてしまった。Elizabeth Hendrickson氏は(リンク)「第3イテレーションぐらいで、全てのユーザの反応が否定的な場合、そのプロジェクトは中止するか、考え直すべきです。」と指摘している。
Robin氏の見解は、プロジェクトが開始する前に、すでにこの失敗の原因は組み込まれていたというものだ。
プロジェクトの発端: プロジェクトの業務ケースは、IT責任者と運用責任者同士の話し合いによって決められていました。それは、現在のプロセスに固執していただけで、プロセスの改良を追求したり、プロジェクト管理をするというものでは無かったのです。
プラットフォームの決定: カスタムメイドのアプリケーションではなく、市販のアプリケーションにインフラを移行すべきだ、という信念によってプラットフォームが決められていました。その結果、プロジェクトの開始に先立って、要件を満たしているツールを誰も試さないうちに決定してしまったのです。さらにこのアプリケーションは、開発チームが使ってみたところ、かなり機能が限定されるということが分かり、業務ユーザは使用に耐えるものではないということに気づいていました。しかし、こういったデータはIT責任者と運用責任者によって却下されてしまいました。
Allan Shalloway氏は(リンク)「現実には力を貸そうと申し出てくれる顧客はいない」ということが正に起きたプロジェクトについて書いている。Allan氏と彼のチームが推していたプロジェクトは、何カ月も後になってキャンセルされた。Allan氏によると、失敗はしばしば次のような原因から起こる。
私のScrumの経験に照らし合わせると、大部分のプロジェクトは、実際にはScrumになっていないのです。どういうことかというと、我々がチームを手伝ったり訓練するためにプロジェクトに参加すると、彼らは「数ヶ月の間Scrumを実践してきました。」と言いいます。しかし、我々が実際に何をしているのかを尋ねると、Scrumとはとても呼べないのです。
後に、Allan氏はこのところ以下のようなScrumの原則をちゃんと理解していないチームをよく見かける、と警告している。
- 一度に一つのプロダクトにのみ集中すること
- チームがビジネス価値に集中できる状態を保つこと
- 強力なビジネス的サポートを得ること
- チームが一丸となってストーリーを実現すること
- 何を以て完了とするのかチームで明確な定義を持つこと
- ...
最後に、Robin氏は(リンク)登山経験もあることから、カナダの山岳クラブが発行している「山岳事故の記録」 について語っている。その記録には多くの登山中の事故が残っているので、他の登山家達はそこにどんな問題があったのかを調べ、自分たちならその状況からどうやって抜け出すか、どう局面を打開するかを考えることができる。彼は、我々にも同様の記録が必要なのではないか、と提案している。「何十億ドルもかかっているのにギリギリの危うい日々。他の工学分野と比較して驚くほど高い確率で失敗するプロジェクト。我々は改めて失敗を記録し、分析すべきではないでしょうか?」
原文はこちらです：http://www.infoq.com/news/2008/07/agile_failures