👾

ふりかえりあるある早く言いたい

岩石

2024/05/22に公開2件

はじめに

はじめまして。レバテック開発部ITSプロダクト開発グループ所属の池永です。

私は現在スクラムマスターとしてチームに参画しており、日々チームが強く、楽しくなれるように試行錯誤しております。
かれこれ一年半ほどスクラムマスターを経験させていただいてきましたが、色んな壁にぶつかってきました。
特にスクラムにおける「ふりかえり（レトロスペクティブ）」において生じた壁について色んなエンジニアと話しているうちに、あるあるなんだなぁ〜と感じたため、この記事を書いております。

この記事では自身のぶつかってきた壁と、そこに対してどのようなアプローチを取ったか、そしてどうなったかを少しだけ共有しようと思います。
何かしらの参考になったら幸いです。

話すこと

スクラムにおけるふりかえりのあるある
- あるあるに対して自分がやったこと
- そのアプローチをとってどうなったか

話さないこと

色んなふりかえり手法について
スクラムにおけるふりかえりの目的

では早速...

タイトルにある通り、ふりかえりあるあるを早く言いたいので、挙げていこうと思います。

1. 暗くなりがち

スクラム導入間もないチームでよくあることだと思うのですが、ふりかえりがまぁ盛り上がりません。様々な要因があるとは思うのですが、自身の経験を例として挙げさせていただきます。

自分が初めてスクラムマスターとして参画させていただいたチームでは、KPT法を用いてふりかえりを行っていたのですが、Keepが全然挙がらず、個人個人の自責のProblemが上がってました。
例えば、
「〜の実装で自分が詰まってしまい、スプリントゴールが達成できなかった」
「〜風邪で休んでしまってタスクが遅れた」
などです。

自責のProblemばかり挙がっている状態でチームの士気も下がり、既に良いところをさらに伸ばす活動が少なくなってしまっていました。

やったこと

レトロスペクティブのルールに一点の変更を加えた

「Keep(よかったこと、続けたいこと)、Problem(問題になっていること)、Try(やってみたいこと)を書く」
↓
「Keep(チーム内でのよかったこと、続けたいこと)、Problem(チーム内で問題になっていること)、Try(チーム内でやってみたいこと)を書く」

どうなったか

Keepについて、自分のよかったことを書くのが恥ずかしいと言っていたメンバーがチームのこととして挙げるのならやりやすいと言ってくださり、Keepが挙がりやすくなりました。
Problemについて、チームとしての問題としてとらえることで、前向きにNextAction(以下:NA)を立てることができるようになりました。
前述の例だと、
「〜風邪で休んでしまってタスクが遅れた」は「いざという時にタスクの担当者を流動的に動かすことができない」という問題に言い換えられ、
「デイリースクラムのアジェンダに巻き取る必要があるタスクがないか確認する時間を追加する」といったNAが生まれました。

基本的に日を跨ぐタスクがないようにタスクを細かくしていた自チームでは、
これにより、その日その日のデイリーでタスクの担当者を流動的に変えられるようになり、スプリントゴールを達成しやすくなりました。

「〜の実装で自分が詰まってしまい、スプリントゴールが達成できなかった」は「〜の実装がチームの形式知になっていない」と言い換えられました。
これにより「モブプロを実践し、〜をチームの形式知とする」というNAが生まれ、実践することで個々人の成長にも繋げることができました。

チームの課題を解決していくことで、個人の課題も解決できることがありました。

気づき

ものすごく単純な変更点だが、少し意識を変えるだけで改善につながることもある
チームの課題に対してアプローチすることで個人の課題も改善することが多々ある

2. Tryが生まれすぎて消化できなくなりがち

チームにスクラムが馴染んできたら、ふりかえりで提起される問題に対して、全ての問題を改善しようと、とてつもない数のTryが生まれます。

自身が参画していたチームでは、初期は「前スプリントのふりかえりで生まれたTryを全てスプリント内で消化する」というルールで運用しておりました。
チームの成長と共に、生まれるTryの数が増え、スプリント内で消化できなくなっていくことで、山積みになったTryはどんどん後回しにされていくようになってしまいました、、、、、

やったこと

生まれたTryに対して優先度をつけるようにした
- 以下の表（ValueEffortマトリクス）に則って優先度をつけ、優先度の高いものから消化していくことにした
優先度が高い順にチームで1スプリント4つずつ消化するようにした
- 人数に関係なく、チームで対応する個数を今までのチームの活動からできそうな現実的な範囲で定めた

	労力が多い	労力が少ない
価値が高い	大	最大
価値が低い	小	中

どうなったか

Tryに対しても優先度がついていることで、プランニング時に今スプリントに実践してみるTryを計画しやすくなりました。
また、今までは「Tryが消化できなかったこと」をふりかえりで悔やんでいたチームが、「効果の高い改善（Try）を行えた」と喜ぶチームへと変貌しました。

気づき

プロセス改善に関しても優先度づけして効果の高い改善から取り組めるようにしておきたい

3. 不要となったルールが増えがち

ふりかえり→改善を繰り返す中でルールが生まれることがあります。
多くのルールが運用が組み込まれると、時には守られなくなってきたものや、そもそも必要がないもの（効果がないもの）が生まれてきます。
そうなってくるとルール全体が軽視され、無秩序になっていく可能性があります。

自分のチームでも、たくさんのTryを実践していくうちにチーム内でルールが無尽蔵に増え、形骸化してしまったものも多くある状態となってしまいました。

やったこと

一度全てのルールを見なおす会を実施した
ふりかえりで今スプリントで追加されたルールや改善活動に対して評価をし、必要がなさそうであれば辞めるようにした
- 実施するかどうかの精査はあまり厳密には行わず、気軽に試す。ダメそうであればすぐ辞められる
- 評価が何とも言えない場合はもう１スプリント試す

一度全てのルールを見なおす会で現存するルールに対して続けるか辞めるかを決めました。
それ以降はふりかえり内で各メンバーから今スプリントで追加されたルールや改善活動に対して同様に続けるか辞めるかを判断する時間を設けました。
効果を数値で測るのではなく、メンバーの所感で決めることにしました。
なぜなら、迅速に判断できますし、もしまた必要になれば今後のふりかえりでTryをして挙がるからです。