レトロスペクティブ後もレトロ施策が効果を発揮し続けるための9つのヒント
広告・HappyScribeとの協力によるスポンサード投稿。
レトロはうまくいきました。全員が率直に話し、チームは重要なテーマを優先し、最後には、全員が賛同する2つか3つの施策が残りました。
するとスプリントが始まります。チケットは積み上がり、ある本番障害が火曜日を飲み込み、木曜日には何が実際に合意されたのか、もう誰もよく分からなくなります。次のレトロで誰かが、コードレビューの件はどうなったのかと尋ねます。沈黙。
レトロ自体がうまく進んだとしても、レトロ施策は失敗することがあります。レトロボードとスプリントボードの間のどこかで、その後の1週間のうちに消えてしまうのです。
良い施策の立て方については、すでに別の記事で説明しました。この記事は、その記事が終わるところから始まります。つまり、レトロが終わった後です。次のレトロが始まるまでのあいだ、成果を生きたものとして保つにはどうすればよいのでしょうか？ 例を交えた、よいレトロスペクティブ施策のための10のヒント.
ヒント1：締めくくる前に、結果をもう一度読み上げる
レトロの最後の5分は、しばしば最も弱くなります。集中力が落ち、次の会議が待っていて、施策は急いで書き留められます。
締めくくる前に、それぞれの施策を声に出して読み上げてください。次の質問に答えられるか、全員で確認しましょう:
- 誰が責任を持つのか？
- 最初の一歩は何で、いつ実行するのか？
- その施策が効果を発揮していると、何をもって分かるのか？
答えのどれかが一文に収まらないなら、その施策はまだ完成していません。全員がその場にいるうちに明確にしましょう。今ここで2分かけるだけで、2週間後の途方に暮れた議論を避けられます。
役立つテストがあります。レトロに参加できなかった人がその施策を読んで、何をすべきか理解できるでしょうか？ もし説明が必要だと思うなら、別れ際までに不足している文脈を補ってください。
ヒント2：それぞれの施策に責任者と最初の一歩を設定する
「チーム」が責任者だと、日常では誰も具体的な当事者だと感じなくなりがちです。
そのため、各施策には名前を一つ書きましょう。その人がすべてを自分でやる必要はありません。役割は、実行状況を見守り、次のレトロで報告することです。
さらに、小さく具体的な最初の一歩も必要です。「コードレビューを改善する」は目標です。「水曜日に2人のレビュアーと30分を確保し、チェックリストをすり合わせる」は最初の一歩です。小さく、かつ時間的に近いほど、追跡しやすくなります。2日以内に実行できる一歩なら、良いスタートです。
たとえば、こんな形です:
| レトロの結果 | 責任者 | 最初の一歩 | チェックイン |
|---|---|---|---|
| より短いデイリー | サム | 明日から、1人あたり2分で試す | スプリント半ばのデイリー |
| スプリントレビューでの驚きを減らす | プリヤ | 火曜日のリファインメントにプロダクトオーナーを招待する | 次のレトロ |
| より明確な「Readyの定義」 | アレックス | 今週中に45分のワークショップを設定する | スプリント半ばのデイリー |
名前と状況は例示です。
ヒント3：決定だけでなく、理由も記録する
レトロの1週間後には、「PRレビューを2人で行う」のような施策が奇妙に見えることがあります。表現は残っていても、その理由はもう忘れられていることが多いのです。
なぜそれを決めたのか誰も覚えていないと、それは優先度を失います。そして次のレトロで成果を尋ねても、本来の目的を覚えている人が誰もいないかもしれません。
そのため、施策の隣に問題も直接書いておきましょう。1〜2文で十分です: 「前回のスプリントではレビューが2日間滞留し、3件のストーリーを止めていた。」こうすることで、共同レビューに価値がある理由が明確になります。
一部のリモートチームでは、レトロのうち施策を決める部分も追加で録画しています。HappyScribe のような AI ノートテイカーは、Zoom、Google Meet、Microsoft Teams の会議に参加し、話者識別つきで会話を書き起こし、その後、アクションアイテム付きの要約を送ることができます。これにより、誰が何を提案し、なぜそうしたのかを追跡できます。 HappyScribe AI 会議ノートテイカー.
気をつけて扱いましょう。レトロは、人々が安心して率直に話せるときにだけ機能します。録画する前にチームに確認し、何を録画するのか、誰がアクセスできるのか、いつ録画を削除するのかを取り決めましょう。誰かがそれを不安に感じるなら、書面でのメモにとどめます。ひとつの妥協案は、オープンなフィードバックのフェーズは録画せず、優先順位付けと施策の計画だけを記録することです。HappyScribe では、会議チャットで録画を一時停止・再開できます。
ヒント4: チームが毎日目にする場所に施策を置きましょう
レトロボードにだけ載っている施策は、すぐに忘れられがちです。そもそもそのボードは日々の仕事の流れに入っていないかもしれません。
そのため、合意した施策は実際に仕事をしている場所へ移しましょう。多くのチームではスプリントボードです。各カードには担当者と最初の一歩を記載します。そうすれば、改善が他の作業と並んでデイリーに現れます。
そのために、改善案でいっぱいの別のバックログは必要ありません。Echometers の推奨はこうです。重要テーマに入らなかったアイデアは、後のチームフィードバックで、なお関連性があるなら再び浮上してくる可能性があります。ボードに載せるのは、実際に合意した施策だけです。
ヒント5: スプリントに改善のためのキャパシティを計画しましょう
レトロでは一つの施策が決まります。その後のスプリント計画では、スプリントは機能開発で埋まっていきます。その施策の居場所はなくなり、気づかれないまま先送りされます。心当たりはありませんか？
スクラムガイドは、最も効果の高い改善にできるだけ早く取り組むことを推奨しています。それらは次のスプリントのスプリントバックログに入れることもできます。 Scrum Guide: スプリントレトロスペクティブ.
だからこそ、レトロで決まった施策は意識的にスプリントプランニングへ持ち込みましょう。誰かが思い出してくれるだろう、と頼らないでください。小さくても、他の作業と同じように見積もりましょう。実際のキャパシティを確保してください。スプリントがすでにいっぱいなら、何か別のものを下げる必要があります。
もし施策にまったく場所が取れないなら、それも重要な情報です。もしかすると、それは正しい施策ではなかったのかもしれません。施策を意識的に捨てるほうが、3スプリントも引きずるよりずっと良いです。
ヒント6: スプリントの半ばで進捗を確認しましょう
2週間は、施策が手つかずのまま放置されるには長い時間です。次のレトロまで待っていると、スプリントの途中で軌道修正する機会を逃してしまうかもしれません。
スプリントの半ばで簡単にチェックインすると、実行が前進し続けます。そのために追加の会議は必要ありません。デイリーで1分あれば十分なこともあります。担当者は次のことに答えます:
- 最初の一歩は終わりましたか？
- 次の一歩を妨げているものはありますか？
- 新しい学びを踏まえて、まだこれが正しい施策ですか？
最後の質問を飛ばさないでください。レトロの後で状況が変わることもあります。途中経過を確認すれば、もう役に立たないものを最後までやり切るのではなく、施策を調整できます。
ヒント7: その日のうちに短い要約を送りましょう
記憶は薄れ、レトロの受け止め方は人それぞれ少しずつ違います。その日のうちに短い書面の要約を送ることで、共通の土台ができます。
スマートフォンでも読めるように、できるだけ簡潔にまとめましょう。たとえば:
振り返りの要約、スプリント14。対応策：次のスプリントではPRレビューを2人一組で実施する。理由：前回のスプリントではレビューが2日間滞留し、3件のストーリーを止めていた。担当：Priya。最初の一歩：水曜日までにレビューのペア分け計画を作成する。確認項目：次回のレトロで、レビューの平均待ち時間を確認する。
それを、日常的にみんなで話す場所、たとえばチームチャットに投稿してください。もう誰も開かないメールでは、あまり役に立ちません。
もし対応フェーズを記録していたなら、AIによる要約を下書きとして使えます。内容を確認し、誤りを修正して、共有する前に例のように数行に短くまとめてください。
ヒント8：複数のレトロを通してパターンを探す
遅いレビュー、あいまいなチケット、連携不足など、何度も繰り返し出てくるテーマがあります。同じ問題が3回連続でレトロに出てくるなら、あなたたちの対応策が本当に効いているのか確認すべきです。
およそ四半期に一度、複数のレトロをまとめて見てください。次の質問が役立ちます：
- どのテーマが繰り返されていますか？
- どの対応策が実施されましたか？
- その根本的な問題は、それによって本当に解消されましたか？
- どの対応策が何度も先送りされ、その理由は何ですか？
繰り返し現れるテーマは、これまで症状にしか対処していなかったことを示しているかもしれません。5Why法のような原因分析は、より深く掘り下げるのに役立ちます。
合意したレトロの一部を文字起こししておけば、古いボードを一つずつ見返す代わりに、共有済みのトランスクリプトを検索できます。たとえばHappyScribe Chatは、トランスクリプトのフォルダ全体に対して質問できます：「この四半期に、1回以上のレトロで出てきた問題は何ですか？」答えは元のメモやトランスクリプトで確認してください。
ヒント9：次のレトロの冒頭で、ひと区切りをつける
次のレトロの開始は、新しいフィードバックを集める前に、対応策を確認するのに適したタイミングです。
Echometerは、過去のレトロにある未完了の対応策を一覧表示することで、それを支援します。ツールに関係なく、各対応策を確認してください：完了しましたか？目標は達成しましたか？継続しますか、修正しますか、それとも取りやめますか？私たちの対応策の記事には、そのための簡単な評価マトリクスがあります。 レトロスペクティブの対応策の評価マトリクス.
少し時間を取って、効果のあった改善を認めましょう。そうすることで、レトロが変化につながることをチームに示せますし、次回も参加しようという意欲を高めることができます。
対応策がうまくいかなかった場合は、答えをもたらしてくれた実験として扱いましょう。次に何を試すか、あるいは意識的に手放すかを決めてください。
結論：レトロは終わっても、実行は続く
良い対応策は始まりにすぎません。ですが、よく書かれた対応策でも、次のレトロまで誰も見返さなければ、あまり意味がありません。
この記事の手順は小さなものです。締めくくりの前に結果を読み上げる。各対応策に担当者と最初の一歩を割り当てる。決定理由を記録する。対応策をスプリントボードに載せ、キャパシティを確保し、スプリント中盤で進捗を確認する。同じ日に短い要約を共有し、定期的にパターンを探し、次のレトロはこれまでの対応策を振り返るところから始める。
その多くは数分でできます。まず一つだけ試すなら、ヒント1から始めてください：明確な責任分担と具体的な最初の一歩で終わるレトロは、その後の1週間に向けて良い土台を作ります。
