レトロで決めたアクションが実行されないのは、意志ではなく件数の問題です

レトロスペクティブでは毎回いくつか改善アクションが出る。ホワイトボードにも残っている。それでも次のスプリントが終わるころには、どれも手つかずのまま次のレトロスペクティブを迎えている。この繰り返しは珍しくありません。

この記事では、決めたことが実行されない理由を意志の問題として扱わずに整理し、実行される状態にするための具体的な進め方を扱います。

担当と期限を決めても消える

最初に試されるのは、責任の明確化です。誰がやるかを決め、いつまでにやるかを書き添える。これは正しい方向ですが、それだけでは足りません。

改善アクションが消えるのは、忘れているからではありません。スプリントバックログの作業と時間を奪い合って負けているからです。開発の作業には締め切りとレビューがあり、改善アクションにはどちらもありません。同じ人の同じ時間を取り合えば、負けるのは常に後者です。

担当と期限を書くことは、この勝負の条件を変えません。書いた本人も実行するつもりでいるので、意志の問題としても扱えません。

見分ける材料があります。実行されなかったアクションについて、担当者が内容を覚えているかどうかです。覚えているのに手がついていないなら、忘却ではなく時間の奪い合いに負けています。

3件決めると0件になる

時間の奪い合いに負ける度合いを決めているのが、件数です。レトロスペクティブは意見を出す場なので、終わるころには複数の改善案が並んでいます。チームの容量に余白がない状態で全部を採用すると、実行されるのは0件になります。

理由は単純で、同時に進める改善を増やすほど、1件あたりに割ける時間が減り、どれも完了しないからです。半分やりかけた改善は、何も変えていないのと同じ状態になります。

工場やソフトウェアの流れの管理で知られる考え方に、同時に手をつけている仕事の数を減らすほど1件あたりが早く終わる、というものがあります。作りかけを増やしても完成は増えない、という見方です。

借りてよいのは「作りかけを増やしても完成は増えない」という構図までで、工場の部品とチームの改善を同じ法則で扱えるわけではありません。それでも実用的な示唆が1つあります。次のスプリントで進める改善は1件だけにすることです。

出てきた改善案を捨てる必要はありません。順番待ちの列に置いて、1件が終わってから次を取り出します。

列に置いたまま何スプリントも動かない案は、そのときのチームにとって重要ではなかったということです。3スプリント動かなかった案は削るか、リファインメントの検討対象に移します。列が長くなると、それ自体が見るのを避けたい対象になります。

実行される形にする3つの条件

1件に絞ったうえで、次の3つを満たす形にします。どれか1つでも欠けると、また消えます。

1. スプリントバックログに入れる

改善アクションを別の場所で管理している限り、この構造は変わりません。スプリントの作業と同じ場所に置き、同じように扱う形にします。

これが効くのは、時間の奪い合いに参加できるようになるからだけではありません。締め切りとレビューのある作業が常に勝つのは、進んでいないことに毎日気づかれるからです。スプリントバックログに入れるとは、改善を検査のループに乗せて、「まだ着手していない」に気づく瞬間をデイリースクラムごとに前倒しすることです。

逆に言えば、別管理のリストとは、気づく瞬間が次のレトロスペクティブまで遅れる置き場のことです。そこにある限り、改善は常に「余裕があればやるもの」の位置に留まります。

見積もりも付けます。ポイントを付けるかどうかは、ベロシティを計画に使っているかで決まります。使っているなら付けないと容量の計算が合いません。使っていないなら「半日か、1日か」だけ話しておけば足ります。

この扱いに抵抗が出ることもあります。改善に容量を割くと、その分だけ機能の開発量が減るためです。ここは隠さずに、減る分を含めてプランニングで合意しておくほうが後々もめません。

2. 1スプリントで終わる大きさにする

「コードレビューの質を上げる」のような大きさでは、着手のしようがありません。1スプリント内で完了が判定できるところまで小さくします。

上の例なら「レビュー時の確認観点を3つ書き出して、次のスプリントで試す」まで落とします。完了したかどうかを、他の人が見て判定できるかが基準になります。

大きすぎて小さくできない改善は、その場では採用しません。順番待ちの列に置き、必要ならリファインメントで扱います。

小さくすると効果も小さくなるように見えますが、実行されない大きな改善より、実行された小さな改善のほうが状況は動きます。大きさを保ったまま順番待ちに置き続けるより、削って通すほうが結果は残ります。

3. 完了の確認を予定に入れる

次のレトロスペクティブの冒頭で、前回のアクションがどうなったかを確認します。これを毎回やると、未実行のまま次の回を迎えたことがその場で分かるため、次に決めるアクションが実行できる大きさに寄っていきます。

確認するのは達成・未達成ではなく、状態と理由です。実行されていないときに責める場にすると、次から小さい改善しか出なくなります。実行されなかった理由のほうに情報があります。

所要は5分で足ります。長い議論になるなら、それは確認ではなく新しい改善の検討に入っています。原理は条件1と同じで、気づく瞬間を「いつか」から「次の回の冒頭」に固定する、いちばん安い仕掛けです。

実行されなかったときに何を見るか

未実行が続く場合、理由はいくつかに分かれます。理由ごとに次の手が違います。

3行目が重要です。チームの外側にある障害を、チーム内の改善アクションとして書いてしまうことがよくあります。他部署の対応待ちや、上位の決定が必要なものは、チームが何回決めても実行されません。この場合は、担当を決めるのではなく、外に働きかける動きに切り替えます。

分類は、実行しなかった本人に聞くのが確実です。推測で分けると「時間が取れなかった」に寄せやすく、置き場所や裁量の問題が見えなくなります。

絞っても動かない場合

1件に絞り、大きさを整え、確認も入れているのに動かないことがあります。この場合、原因は運用の外にあります。

考えられるのは、改善に使える時間がスプリントに一切確保されていない状態です。スプリントの計画が常に容量いっぱいで組まれていれば、改善は入る余地がありません。この場合に必要なのは、改善の運用を工夫することではなく、計画の量を減らす交渉になります。

もう1つは、改善しても状況が変わらないと学習されている場合です。この状態は運用では戻せず、まず1件、確実に完了して効果が残る改善を通すところからになります。見分け方そのものは、レトロがマンネリになる話として別記事で扱います。

判定するには、直近3回のレトロスペクティブで決めたアクションを並べ、実行されたものが1件でもあるかを見ます。1件もないなら運用より前の段階に問題があります。

明日からの一歩

次のレトロスペクティブで、出てきた改善案のうち1件だけを選んでスプリントバックログに入れてください。残りは順番待ちの列に置きます。

そのうえで、次の回の冒頭で結果を確認する時間を5分だけ確保してください。実行されていなければ、上の表で理由を分類します。理由が分かれば、次に変えるものが決まります。