プラクティス名（別名）
レトロスペクティブ （ふりかえり、レトロ、スプリントレトロ～、リリースレトロ～、プロジェクトレトロ～）
※スプリントレトロスペクティブ ：スプリントの最終日に行うふりかえり
※リリースレトロスペクティブ ：リリースを行うたびに行うふりかえり
※プロジェクトレトロスペクティブ：プロジェクト完了後に行うふりかえり
プラクティスの目的・狙い
- 気づき、学びの共有
- チームの成長
- 関係の修復
どんな時に使うか
- スクラムでは必須（最低限スプリントレトロは実施する）
- チームの問題を解消したい時
- チームを改善し、方向性を軌道修正したい時
実施手順
※以下はスプリントレトロの想定です
- スクラムチーム全員でふりかえり、良かった点や改善したい点について話し合う
- 主な観点は５つ「個人」「相互作用」「プロセス」「ツール」「完成の定義」
- プロダクトの課題より、チームの課題（活動やコミュニケーション）に着目する
- 次スプリントで行う改善アクションを最低1つは決める（多すぎてもよくない）
とくにスプリントゴールが未達に終わった回はPOとDEVの間に溝ができがちなため、原因と対策について掘り下げ、同じ失敗を繰り返さないように最大限努力する。納得感のある改善策を提示することでPOとの関係を修復することができ、前向きな気持ちで次のスプリントに臨むことができる。これはDEV間の関係についても同様。
アレンジ例
- KPTやYWTといったフレームワークを使って事前に各自で意見を書き出しておく
- 2週間スプリントだが、レトロスペクティブは毎週実施する
アンチパターン
- 発言が特定のメンバーに偏っている、そもそも参加していない人がいる
- 悪かった点ばかりに注目してしまい憂鬱なイベントになる
- 特に困ってることは無いので改善点も無い、という誤解（＝向上心が無い）
参考情報
こぼれ話（私的コメント）
ウォーターフォール出身の方は「ふりかえり」と聞くと将来に向けて"できればやっといた方がいいもの"ぐらいの感覚で理解される方が多いのですが、スクラムにおいては"絶対にやらないとダメなヤツ"です。レトロをやらずにどうやってスクラムを回すのか、という話ですね。
そこで結構、悩むのが誰がファシリテーターを務めるべきか、という話。定番はSMだと思いますが、DEVが主体性を持ち始めたら任せてもいいと思いますし、チームをリードしてくれるPOだったらその人が適任かもしれません。避けた方がいいかもと思うパターンは持ち回り制ですね。レトロをきちんと回すってそんなに簡単じゃないので、ある程度は一人に集約した方がよいかと。
余談ですがアジャイルでは「振り返り」ではなく「ふりかえり」とひらがなで表記することが多いです。(経緯は省きます。悪しからず。)