価格と完了日が決まっているプロジェクトをスクラムとどのように組み合わせるか? Tim van Baarsen氏が、水面下でスクラムに取り組みながら、すべて決まっているプロジェクトを完成させた自分自身の経験について考察した。
最初の要求からバックログを作成し、Tim氏のチームは、定期的なスプリントで繰り返しリリースをし始めた。進捗を示し、バーンダウンで視覚化することで、非常に細かいタイムボックスと仕様がなくても、予測可能になり、うまく適応できるようになった。そのプロジェクトは、予算内で期日通りに納品された。
完全に制約のあるプロジェクトにおけるスコープの調節方法を理解するのを助けるために、Tim氏は次のように書いた。“「すべてが決まっているプロジェクト」でも、要求はその内に変わることは分かっています。いつもそうですから。”
そして、続けて述べた。“変更要求は、私たちのアジャイルアプローチにはあまり合っていません。それでも、できるだけ柔軟に対応したいので、なるべく要求を交換するようにします。”
Tim氏は、“要求の交換”のことを、理解できる範囲で変更を扱う仕組みとして述べている。余分なストーリーやあまり重要ではないストーリーを新しいものと取り替えれば、ストーリー全体の大きさは変わらない。これらの“要求の変更”を通して、作業の全体量を一定に保つことで、変更のリスクは軽減される。
2013年の初めに、Peter Vaihansky氏が、大きなプロジェクトを完全に制約できるかどうかという疑問を投げかけた。McKinseyとOxford大学のBT Centre for Major Programme Managementによる調査を引用して、すべてが決まっているプロジェクトの成功は神話であると、Peter氏は指摘する。その調査は、5,400以上のITプロジェクトやソフトウェアプロジェクト(特に大規模なもの)を調べたもので、平均して、66パーセントのプロジェクトが予算を超え、33パーセントはスケジュールが遅れている。
Peter氏の記事は、すべてが決まったプロジェクトは、大抵、フィードバックループの欠如が原因で失敗すると述べている。Peter氏によると、決まった価格を決まった予算に置き換えることでこれは解決できる。”あなたの財政的な支出は上限が決まっていて、締め切りもおそらく決まっています。しかし、プロジェクトが実際にどのように進んでいるかという現実に基づいて、範囲は変化し、要求も変わるでしょう。”
アジャイルプロジェクトの成功は、常に関係する人々にかかっている。プロジェクトの最初に、Tim氏は、クロスファンクショナルな“タイガーチーム”を作った。また、Tim氏は従来のプロダクトオーナーが必要であることも認識していた。完全な仕様は“プロジェクトを実施するために必要なこと”に絞り込まれ、誰かが顧客の要求を理解し、責任を持って決定していた。
プロダクトオーナーと要求を変更するプロセスを通して、チームは時間を延ばさずに、変更に応える手法をやって見せた。プロダクトオーナーがスコープを調節することで、最低限実現できる製品が、決まった時間内に納品できたのだ。