[スクラム]スプリントレトロスペクティブの定義と運用事例(前編)(2024 Advent Calendar 8日目)
この記事は私をシニアエンジニアにしてくれた「真のアジャイル開発」体験記の8日目の記事です。このアドベントカレンダーは「ある機能開発チームでスクラム, XP, DevOps を一度に実践したら真のアジャイル開発ができた」という内容です。執筆者は全てプログラミングをするパンダです。
スプリントレトロスペクティブ
本記事ではスプリントレトロスペクティブの定義と自分たちのプロジェクトでの運用を紹介します。
前編ではスプリントレトロスペクティブの定義と運用に焦点を当て、後編ではレトロスペクティブを通して改善されたことを紹介します。
スプリントレトロスペクティブの定義
スプリントレトロスペクティブは、そのスプリントを振り返ることでチームの自己組織化を促進するためのイベントです。このため単に振り返り会と呼ばれることもあります。スプリントを1イテレーション実施した結果、スプリントゴールが達成できたのか、もし達成できなかった場合にはどのようにすれば達成できたのかをチームで振り返ります。これからはこうすればうまくいくだろうという改善策を話し合って次のスプリントに活かすのです。
この振り返りではスプリントのアイテムに対する反省だけでなく開発プロセスや開発のプラクティスはもちろんのこと、そのスプリント内で発生した事象に関するチーム内外の全てを議論の対象とします。課題を特定してチーム全体で改善に取り組むことで、深い学習をして経験を知恵に変え、開発プロセスの品質向上を目指します。
スプリントをただ実施するだけではスクラムチームに向上はありません。そうではなく、スプリントが終わったらレトロスペクティブでしっかり振り返りと改善を繰り返すことでチームは着実に前進します。こうした絶え間ない改善の積み重ねこそが強いスクラムチームを作り上げるのです。
スプリントレトロスペクティブの運用
運用のポイント1: KPTではなく「思ったこと・問題点・解決策・ネクストアクション」で実施する
自分のチームではスプリントレトロスペクティブを1回1時間で実施しています。イテレーションが1週間の場合でも2週間の場合でも長さは同じです。具体的な方法としては「思ったこと・問題点・解決策・ネクストアクション」という独自のフレームワークを採用しています。これは開発初期に使用していたKPT(Keep, Problem, Try)を改良したものです。
初期の段階ではKPTを使って振り返りを行っていました。各メンバーがKPTのそれぞれの項目に対して3〜4つのアイデアを付箋に書いて口頭で発表するのです。しかし当時のチームは8人だったため、1時間では全てをカバーするのが難しいという課題がありました。また、「Keep」に関しては書き出して改めて意識しなくてもチームで自然に継続できている内容が多かったため、振り返りの時間を「問題点や改善のアイデア」に集中させた方が有益だという意見が出ました。
KTPの次に「問題点・解決策・ネクストアクション」の3段構成をチームで採用しました。しかし、それだけだと事務的で窮屈だと感じたプロダクトオーナーが「なんとなく思ったことでもいいのでもっとカジュアルに色んなことを共有したい」と提案しました。そこで元々の「Keep」を「思ったこと」に置き換え、気軽にアイデアを出せるようにしました。実際、「思ったこと」は自然と他のチームメンバーへの感謝ややってよかったことなどが書かれるようになりました。これらの変更により、良い雰囲気の中で時間内に十分な議論ができるようになりました。
振り返りの具体的な方法をさらに詳しく述べます。レトロスペクティブはコラボレーションツールのFigJamを利用してオンラインで実施しています。まず、3〜5分ほど時間を取ってチーム全員が「思ったこと」を自由に記述します。この段階ではポジティブな感想でもネガティブな意見でも自由に書いて良いこととしています。制限時間が終われば全員が書いた内容を発表して意見を共有します。類似するアイデアやテーマが書かれた付箋はグルーピングします。
全員の発表とグルーピングが完了したら、付箋グループに対して一人3票の投票を行います。投票の結果、得票数が多い上位2つの項目を「解決したい課題」として選んでそれを「問題点」のエリアに移します。さらに再び3分ほど時間を取り、全員がその課題に対する「解決策」を付箋に書き出します。その後、各自のアイデアを発表してチーム全体で議論を進めます。
議論を通じて、ファシリテーターは解決アイデアを具体的に実行できる「ネクストアクション」に書き換えて提案します。ネクストアクションの中で、チーム全員が合意できた内容を次回のスプリントで実行に移します。このプロセスを2つの課題に対して繰り返すことで、効率的かつ集中した振り返りが可能となっています。
運用のポイント2: レトロスペクティブは必ずしもKPTで行う必要はない
レトロスペクティブは必ずしもKPTで行う必要はありません。そもそもスクラムガイドは振り返りに関する具体的な手法を指定していないからです。
自分達のチームでこれをやってみたいというプラクティスを採用するのが良いでしょう。KPTなど既存の振り返りフレームワークを使っていても改善効果が十分ではないと感じたら、その手法自体が適切なのかをレトロスペクティブで俎上に上げましょう。
どんなチームにも最適な万能解というものは存在しないため、現在チームを構成しているメンバーが満足する方法を探して採用しましょう。
後編ではレトロスペクティブを通してチームで改善したことを5つ紹介します。
Happy Coding 🎉