レトロスペクティブ
シンプルなルール
Program Manager / Project Manager がミーティングのファシリテーターを務める
レトロスペクティブのスコープは、直近のスプリントまたは終了したエンゲージメントに焦点を当てる
ミーティング参加者:
- Program Manager / Project Manager
- Technical Architect
- エンゲージメントチーム
- イテレーションレベルのレトロスペクティブでは、顧客や他のステークホルダーなど、他の参加者がいることも可能ですが、これは完全にチームが決めます
- 最終エンゲージメントレベルのレトロスペクティブでは、GitLab またはパートナーのチームメンバーのみが参加すべきです
- レトロスペクティブ中、チームは本質的な 3 つの質問に集中します:
- 何がうまくいったか？
- 何を変えたいか？
- その変更をどのように実装できるか？
スプリントレトロスペクティブを有用にする鍵は「アクション重視」を保つこと（アクションへのバイアスを持つこと）です。チームは自分たちのプロセスをより良くするために何を変えられるかに集中する必要があります
ミーティング時間は固定: スプリント期間 1 週間ごとに 45 分
時間経過に伴うプロセス改善の管理
述べたように、レトロスペクティブは アクション重視 であるべきです。意図はプロセスを迅速に改善し、より良い生産性を可能にすることです。
しかし現実には、改善提案の中にはすぐに対処できるもの、時間がかかるもの、チームの意思決定範囲外または エンゲージメント期間を超えるものもあります。
改善提案のアイデアが何で、どのカテゴリに属し、どのスプリント／リリースで最初に出てきたかなどを追跡するため、改善提案のランニングログを保つことが推奨されます。
これによりチームのアカウンタビリティを保ち、時間とともに実装したすべてのプロセス改善を覚えておけます。
改善提案が当てはまる時間枠は次のとおりです。
次のイテレーション／スプリント以内
次のイテレーションの過程で達成できる改善提案。たとえば特定の CI ジョブのリファクタリング。クイックヒット、クイックサクセスです。
複数のイテレーション／スプリントにわたって
実装に 2 つ以上のイテレーション／スプリントが必要な改善。サブシステムの再設計、または包括的に長期の承認を取得するなど、1 スプリントで完了できないタスクがこのカテゴリに入ります。
次のエンゲージメント以降
現在のエンゲージメントを超えて調整するもの。たとえばオンボーディングプロセスの改善で、現在のエンゲージメントのデリバリーフローを中断しないようにします。
決して
そう、改善提案の中には決して対処されないものもあるという考えを好まない人もいますが、こういう状況は誰もが知っています。たとえば、自動化タスクが実装できれば良いものの、実装にかかる労力が長すぎて ROI を実現できない場合、おそらく決して実装しないでしょう。
これは「決して」カテゴリに入る改善提案です。決して起こらないかもしれないからではなく、影響とスコープの観点でチームが決定できない判断だからです。
よくある課題と対処法
Boiling the Ocean（海を沸かす）
レトロスペクティブ中にチームを軌道に乗せ続けるのは Program Manager / Project Manager の責任です。チームには「Boiling the Ocean」カテゴリに入る問題に焦点を当てる傾向がある場合があります。
それらは時には素晴らしい議論トピック（特にミントティーを片手に長い夜を過ごす場合）ですが、ほとんどの場合、チームのスコープと影響範囲外にあります。
レトロスペクティブが有用で良い改善提案を生み出すように、チームはこの種の議論トピックを避け、議論をガイドする 2 つのパラメータに焦点を当てるべきです。
改善提案はスコープ（直近のイテレーション／現在のエンゲージメント）に関連していますか？
改善提案はチームによって達成可能ですか？
不参加
数年前、あるチームメンバーがレトロスペクティブへの参加を拒否しました。なぜか尋ねたところ、彼はこう言いました:
"レトロスペクティブは Lessons Learned ミーティングのようなものとされていますが…私たちは何も教訓を学ばず、2 年前と同じ問題をまだ抱えているので、なぜ時間を無駄にするのですか？"
彼の指摘は完全に妥当でした。スプリントレトロスペクティブを機能させるには、関連性のあるもの（直近のイテレーション／現在のエンゲージメント）と、チームが実際に実装できるものに焦点を当てる必要があります。どの改善提案が出されたか、どれが実装されたかなどをログに記録することで、チームのアカウンタビリティを保ち、進捗も示せます。
責任のなすりつけ合い
改善提案は、責任が割り当てられているような匂いがしてはいけません。オープンなチームコミュニケーションを持ち、チームによって何が改善できるかを正直に評価することが重要です。責任を割り当てるのではなく、潜在的な解決策に焦点を当てるよう注意してください。
すべて素晴らしい／すべてダメな態度
不合理な熱狂と、打ちひしがれた終末予想の両方に注意してください。両極端は通常非現実的です。プロセスは常に改善でき、物事は一部の人が見せるほど悪くないものです。
前回のレトロスペクティブからの改善なし
もう一度、改善したいことを追跡し、それが 1 スプリントのスコープ内であれば、次のスプリントのバックログに入れます。
一般的なガイダンスとして、初期スプリントではキャパシティの最大 20% をプロセス改善のために確保するようにしてください。後のスプリントではそれが 10% に下がるかもしれません。ここでのポイントは、この作業を考慮する必要があるということです。それは独りでに、またはすでに完全に活用されているチームに加えて起こるものではありません。
プロセス改善活動は、イテレーション活動の一部であって、それに加えてのものではありません。
