id:radiocat です。
スクラムは銀の弾丸ではないので、いつもうまくいくとは限りません。今回は私たちのチームの失敗事例をご紹介します。
以前の投稿 でも紹介しましたが、私たちのチームは1週間スプリントを採用しています。以下のように木曜に計画を立ててスタートし、翌週木曜にレビューを行う流れです。
ご覧のように開発に注力できる期間は実質4日しかありません。油断するとすぐにレビューの日を迎えるので緊張感があります。そして、その緊張感にさらに拍車をかける要素がスプリント期間中の「休日」です。
連休の狭間の期間はスクラムを進めるべきか？
ご存知の通り、2018年の9月は2週続けて月曜が休日となる期間がありました。このままだと開発が実質3日しかないスプリントが2回続きます。
さらに、この連休期間を利用して2人の主力メンバーが休暇を取ることになりました。5人チームなので開発力は半減します。チームはこの期間をどう過ごすべきでしょうか？
連休の狭間もスプリントを進める選択
ご察しのとおり、我々はこのままスプリントを進めました。とはいえ、さすがに丸腰でこの状況に立ち向かうほどの度胸はないので、我々なりに対策を立てて取り組もうとしました。まずはその対策をご紹介します。
連休期間のスクラムイベントは中止する
全員揃っていない状態なのでスプリントレビューは1週間スキップすることにしました。ただ、連休前の金曜から着手したスプリントを中断するのはもったいないので以下のように進めることにしました。
個々の開発は進めて良い
中途半端に作業を中断して別の事をやるのも気持ちが悪いので、出社しているメンバーは出来る範囲で開発は進めておくことにしました。ただし主力不在で開発チーム内でのフォローやレビューは手薄になるので、無理せず出来る範囲で作業を進めて、主力メンバーのレビューが必要な作業などは連休明けまで保留するようにしました。
狭間の4日間で1日分の実績を目標にする
主力2人の休暇でチーム全体のパフォーマンスは低下しますが、残りのメンバーだけでも4日あれば普段の1日分ぐらいの実績は充分達成出来るだろうと考えました。そうすることで結果的に2週間の合計が4日分の実績となるので、いつも進めている1週間スプリントと同じぐらいのベロシティを目指すことになり、感覚的にもわかりやすい目標になります。主力不在とはいえ4日で1日分なので、出勤しているメンバーにも負担がかからないはずです。
プランニングと共有をいつも以上にしっかり行う
念のため、休暇の前日に改めて主力メンバーが考えているスプリント中のタスクの進め方をチームのメンバーへしっかり共有して引き継いでもらいました。
下がりきらなかったバーンダウンチャート
結果的にこのスプリントでは、残タスク量を示すバーンダウンチャートの実績が次のようになりました。
微妙な結果です。大負けというほどでもなく、微妙な感じが逆に気持ち悪いくらいです。しかし、このスプリントのふりかえりはチームに疲弊感が漂い、私も含めてみんなモヤっとした状態で改善アクションもうまくまとめられないままスプリントは終了しました。
なぜ計画どおりにスプリントが終わらなかったのか？
いったい何が問題だったのか、後日スクラムコーチに相談してみると3つの課題が見えてきました。
スプリントを進めるのに十分な体制ではなかった
私たちのチームのメンバー構成を改めて整理すると次のようになっています。
現在進めているプロジェクトの在籍期間が1年以上のメンバーが誰もいない状況で、目に見える人数以上にチームの体制は弱くなっています。さらに実はこのスプリントの前半の主力メンバーが休暇に入る直前まで、チームを助けるべきスクラムマスターは出張先からリモートでチームの活動に参加しており、開発チームの状況を詳細まで把握出来ない状況にありました。いつも以上にしっかり共有してから休暇に入るという事前の対策は開発チーム内の個々のメンバーの感覚に託されており、客観的にみても対策できているといえる状態かどうかは誰もわからない状況になっていました。
バックログがReadyではなかった
さて、上記のバーンダウンチャートは狭間の4日間を1日の実績としてまとめていますが、これをそれぞれの日ごとの実績に分けてみると次のような実績になっていました。
主力メンバーが休暇に入った初日から実績が上がらず、残タスクが全く減っていません。すでに危険な状況に突入していることがわかります。実はこのとき、プランニング時点の想定が覆ってそのままではタスクを進められないことがわかりました。スクラムマスターはチームの状況を察知し、いったんタスクの終了条件を見直したりスプリントのゴールを見直すなどの調整を行い、一度は残タスクが減りましたが、すぐにまた別の問題が発生して逆に残タスクが増えてしまいました。
結果的にこの時着手していたバックログは最初からReadyではなかったのです。つまりこのスプリントは前半時点ですでにコールド負けが決まっていました。
しかし、1つ目の原因にあるとおり、チームの体制が不十分で、前半時点ではこの状況を正しく判断できるメンバーがいませんでした。スクラムマスターはチームの状況を正確に判断出来るだけの情報をキャッチできていなかったため場当たり的な対策を取ってしまい、結果的にはコールド負けしたチームにそのまま試合続行を促すことになってしまいました。
仕掛りがたまっていて手当てが追いつかず
チームはそれでもなんとかスプリントのゴールを目指そうと取り組みました。休暇が明けてから、主力メンバーの頑張りによってなんとか持ち直しますが、計画していたゴールには到達できませんでした。
バーンダウンチャートを見るとスプリントの最後で残タスクの消化が少なくなっています。実はこのとき、仕掛中のタスクがたくさ増えすぎて経験のある主力メンバーでも残りの期間で全てを手当することは出来なくなっていました。スプリント前半に発生した問題をなんとかしようとして計画時の想定とは違う進め方をしたり、いったん保留して他のタスクに手を出した結果、想定以上に仕掛り中のタスクが増えてしまったのです。
コールド負けしない鉄則
実はこれらの原因は既にスクラムコーチの吉羽さんが別の場で示されているものでした。
slide.meguro.ryuzee.com
この資料の中でアジャイル開発でコールド負けしないための5つのポイントが挙げられています。
- 十分条件で開始する
- Readyなプロダクトバックログ項目だけ着手する
- 同時の仕掛りを少なくする
- フィードバックサイクルを回し続ける
- 技術に投資し続ける
我々は5つのポイントのうち3つを犯してしまっていました。コールド負けしてしまっても仕方ないですね。スプリントを進めるにあたり、改めてこれらの3つのポイントが重要であることを痛感しました。
- 開始するのに十分な条件か？
- バックログはReadyになっているか？
- 仕掛りが増えすぎる進め方をしていないか？
それでも、我々はこの1回のスプリントでとても大きな学びを得たとも思っています。今後はこれらをしっかり意識してチームで取り組もうとしています。
REGIONAL SCRUM GATHERING TOKYO 2019 のCfPを出しました！
2019年1月9日〜11日に大崎ブライトコアホールで1年に1度のスクラムのビックイベント「REGIONAL SCRUM GATHERING TOKYO 2019」が開催されます。
2019.scrumgatheringtokyo.org
私たちのスクラムの取り組みを多くの方に知っていただき、そして私たち自身が学びを得るためにプロポーザルに応募しました。下記のリンクをご確認いただき、ご興味のあるかたは是非likeをお願いします（締切が10月末ですのでご注意ください）。
https://confengine.com/regional-scrum-gathering-tokyo-2019/proposal/7956/-confengine.com
REGIONAL SCRUM GATHERING TOKYOでは毎回たくさんの素晴らしいセッションが行われますので、スクラムに興味のあるかたはぜひチケットを入手してご参加いただければと思います。
