はじめに
はじめまして。レバテック開発部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をして挙がるからです。
どうなったか
不要なルールや活動が毎スプリント精査され、重要なルールだけが残るようになりました。
また、効果があるかすぐにはわからないものに関しても辞める選択肢があることで試しやすくもなりました。
仮説検証プロセスが素早く回ってる感じがして良い感じでした。
※ちなみに前述の「改善タスクを優先度が高い順にチームで1スプリント4つずつ消化する」というルールも各ふりかえりで精査され生まれたもので、元々は「1人1個ずつ」だったりしました。
（ルールがチームの状況に適応していってて良かったです）
気づき
- Tryとなると、何か新しいことをやりたくなるが、辞めてみるTryというのも大事
- スクラムの実践にはプロダクトの柔軟性だけではなく、プロセスも柔軟である必要がある
終わりに
本記事では自身の経験をもとにいくつかの「あるある」に対してどのようなアプローチをとったかを紹介させていただきました。
これらの実践をしていったことで自チームのメンバーからも以下のような声が挙がりました。
「メンバーの休みがあってもスプリントゴールの達成ができるようになった！！」
「改善に関しても優先度が決まっているので何からやるかわかりやすい！！」
「試してみたいことが挙げやすくなった！！」
とっても嬉しかったです。
こういう声が聞けた時に自分はスクラムマスターとしての喜びを感じます👍
まとめ
今回のあるあるの改善に取り組んでみて、学べたことをまとめます。
- スクラムにおけるふりかえりは基本的に個人ではなくチームにフォーカスしよう
- ふりかえりで生まれたTryにも明確な優先度をつけよう
- 開発プロセスにも柔軟性を持たせるにはどうしたらいいかの意識を忘れない
以上です。参考になったものが一つでもあると嬉しく思います。
参考
記事：KPT法とは？効果的な振り返りの方法や利点・欠点、テンプレートなどを紹介
記事：アジャイル開発におけるレトロスペクティブとは？手法・やり方事例
書籍：現場で見つけた144のヒント アジャイルに困った時に読む本
書籍：アジャイルなチームをつくる ふりかえりガイドブック 始め方・ふりかえりの型・手法・マインドセット
レバテック開発部の公式テックブログです！ レバテック開発部 Advent Calendar 2024 実施中: qiita.com/advent-calendar/2024/levtech
Discussion
有益な情報共有、ありがとうございます！
最後まで言わないやつかと思ってしまいましたｗ
コメントありがとうございます！！
あるあるを書くにあたってよぎったタイトルにしてしまいました笑
申し訳ありません、、、、、笑