ウォーターフォールからアジャイルへの移行で見られる失敗例
アジャイルの手法はいくつかあるが、船橋氏は世界のアジャイル開発の取り組みを調査した「State of Agile Report」の2021年の結果では、66％がスクラムを採用していることから、スクラムをベースにその後のセッションを展開した。
ウォーターフォール（V字モデル）のプロセスを採用したプロジェクトでは、インプットとアウトプットが明確に定義されていて、そのアウトプットである成果物や書類を完成していること、そしてそのレビューをして次の工程にすすみ、リリースを目指す。後工程での変更は前工程にさかのぼって反映させる必要がある。V字の前半（要件定義や設計、実装、初期のテスト）は開発チーム、後半（結合テスト、総合テスト、受け入れテスト）は品質保証のチームが担当する。
要求要件定義、基本設計と詳細化していく過程で、個々の機能詳細化、明確化していくので、フロントエンドの担当、バックエンドの担当など役割が固定される。各インターフェースは仕様書をもとにつながっているものの、個別具体的な部分の担当となっているので、担当外の領域がわからず全体的な把握がしにくい。
一方、スクラムの場合は最大4週間のスプリントを繰り返す活動となります。工程の概念はなく、開発活動期間も短いので必要最低限のドキュメントによってチームが共通認識を得る形を重視して進む。優先順位をつけたプロダクトバックログに順々に対応していくため、プロダクトバックログには改善事項だけでなく、どのような価値を与えるかにまで言及することも多い。設計、実装、テストの過程において全体の統制が意識される。
船橋氏は、ウォーターフォール（V字モデル）からアジャイル（スクラム）への移行がうまくいかない組織は、従来の開発チームが担当していた部分をスクラムチーム化して、品質保証チームは変わらず最後に対応する体制を構築しがちだと指摘した。
「その結果、本来動くプロダクトを重視しているはずが、スプリント内でリリースすることができないため、フィードバックを得られません。品質保証担当が取り残されているためリリース頻度の早期化というのも行いません。継続的に価値を提供することができない典型的な例です」（船橋氏）
船橋氏は、SHIFTが改善を担当した、ある金融プロジェクトを具体例として紹介した。SHIFTはこのプロジェクトのチームAから総合テストをしてほしいと依頼を受けた。スプリントは4回実施され、スプリントのたびに不具合の数は増え、スプリント4では重大な不具合が生じてテストが中止となり、アジャイルをやめてウォーターフォールに戻すこととなった。
「開発部隊と品質保証部隊は分かれているのだから、スクラムチーム化しても結果的にプロセスは変わりません。プロジェクト全体で一つのチームになれば解決すると考えますが、そう簡単にはいかないです。従来の工程に縛られて各々のタイミングで活動していた部隊同士がある日突然今日から一緒に活動しましょうっていうのは無理があります」（船橋氏）
完成に近づいたプロジェクトに対して総合テストをし、非機能テストをするなどの活動をしていたウォーターフォール型チームの場合、アジャイルになってさまざまなテストをどのタイミングで行えばいいかわからないという問題が生じるのだ。
続いて船橋氏は、同じ金融プロジェクトの別のチームの例（チームB）を示した。スプリント5回のうち、スプリント3と4では不具合の検出は低いものの、スプリント5ではテストケースがほかと比べて多く、テストケースが実施できていないように見える。このチームは開発や評価の方法も定まらずメンバーの関係がぎくしゃくしてしまい、安定したパフォーマンスが出せなかったという。
