背景
インフラチームの小川です。
自分たちのチームでは例に漏れずスプリントの終わりにふりかえりを行っていますが、ここ最近はゆるやかな形骸化を感じていました。具体的には、以下のようなことがたびたび起きていました。
- アイデアや問題が出てこない
- ただアジェンダをこなすだけの雰囲気が漂っている
- ふりかえりの効果が感じられない
一定成熟したスクラムチームにおいては、いずれも身近なケースだったりしないでしょうか。
対策
「ふりかえりのふりかえり」を実施しました。文字通り、普段のふりかえりを見つめ直すものです。海外では Retrospective of Retrospectives (RoR) と呼ばれているようで、Rails みがあります。
流れ
課題管理には GitHub Projects のボードを利用しました。
- 課題の洗い出し
- 通常のふりかえり後に、考える時間を何回かとる
- 出た課題を議論しながら新たな課題を見つける (アイデアの発散)
- 課題の整理
- 類似する課題をまとめる
- ドット投票
- 優先度の高い課題を選ぶ (アイデアの収束)
- 対策の検討
浮き出た課題
投票の結果、「ふりかえりの目的がわからない」ことが喫緊の課題であることがわかりました。確かに、現状は目的がチーム内で共有されておらず、かつ明文化されていませんでした。
そこで、まずはチームにおけるふりかえりの目指す姿を固めました。アジャイル的には「希望と懸念」と呼ばれる手法です。チームによって結論は異なってくると思いますが、自分たちは「よりよいチームの運営に役立つ」ことがふりかえりに求めることでした。
次に、何ができれば「よりよいチーム運営に役立つ」のかを深堀りして考えた結果、チームのパフォーマンスを高めながらモチベーションを保つことで、チームが掲げる MBO の達成に寄与できること、にたどり着きました。
つまり、ふりかえりに期待することは、よりよいアウトカムを得るための土台となることでした。
アクション
- チームのスクラムドキュメントにふりかえりの目的を明文化
- 当面はふりかえりボードの目立つところにもカードを作って置いておく
目的がわかれば万事解決というわけでもないですが、どちらかというとより効果的なアクションが生まれるきっかけになってくれることを期待しています。
所感
ふりかえりの目的をチームで明確化できたのは良かったです。ふりかえりに限らず、スクラムイベントが形骸化していくことは定期開催している以上は避けられないと思っていますが、暗礁に乗り上げた際は、都度目的を確認することで正しい舵取りができるとベストです。
一方、目的を明らかにすることで得られるものもあれば、失うものもあるように思います。目的を定めたからそれで終わりではなく、スクラムのベースとなる経験主義に基づき、適宜目的を見つめ直していくことが大切ではないかと考えています。
また、「ふりかえり」は定期的に行われていることから「ふりかえりのふりかえり」も定期的に行うのが理想です。しかし、それはそれで「ふりかえりのふりかえりの形骸化」の恐れもあるので、今回のように違和感を覚えたタイミングで随時やっていくのが落とし所かな、という気もしています。
スクラムイベントが「ただこなすだけ」の時間になってきたと感じたら、一度立ち止まってチームで話し合ってみてはいかがでしょうか。
参考
- もっとポジティブなプロジェクトを目指してFun, Done, Learnを始めてみた - OpenWork Tech Blog
- アジャイルなチームをつくる ふりかえりガイドブック
- ゾンビスクラムサバイバルガイド
最後に
インフラチームでは 1 週間ごとに小さくスプリントを回して、プロダクトや開発者への継続的な貢献を行っています。興味のある方は採用サイトを覗いてみてください。
