職業柄色々なプロダクトのスクラムチームを見ることがある。
で、いくつかのチームで共通する、形骸化したふりかえりのあるあるパターンの１つ。
個人のふりかえり → 個人の反省 → 個人の改善になってるパターン。
「風邪を引いて作業が進まなかった」→「体調管理に気をつける」
みたいなやつ。
作業が進まなかったのは チームの問題 なので個人の問題のままに改善しようとしているならスクラムマスターを何とかした方がいい。
第一、個人のふりかえりと改善なんてスプリント終わりまで待たずに毎日やってくれていい。
スクラムガイドを見ると、
https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
スプリントレトロスペクティブは、スクラムチームの検査と次のスプリントの改善計画を作成する機会である。
(中略)
スプリントレトロスペクティブには、以下の目的がある。
• 人・関係・プロセス・ツールの観点から今回のスプリントを検査する。
• うまくいった項目や今後の改善が必要な項目を特定・整理する。
• スクラムチームの作業の改善実施計画を作成する。
スクラムマスターは、次のスプリントが効果的で楽しいものになるように、開発チームにスクラムプロセスフレームワークの範囲内で開発プロセスやプラクティスを改善してもらう。
チームのやり方を見直して、改善するのがレトロスペクティブの目的。
これを忘れるといつまでもチームとしての能力は大して上がらない。多分絶対に。
こうなるチームの特徴の１つが、ストーリーを人にアサインするアンチパターンがある。
Ryuzee さんのブログに詳しいので詳細はそちらを。
このスタイルで作業を進めると、「レビュー待ちです」「あとはマージだけです」みたいな会話をレビューでよく聞く。いや終わってないからそれ。
そもそも スクラム なんて読んで字のごとくラグビーの話じゃないですか。
どこの世界に各自1個ずつボール持ってヨーイドンするラグビーがあるんです？
というわけでスクラムのレトロスペクティブにおいて、個人のふりかえりにはあまり興味はない。敬意はある。くらい言わないと伝わらない気がしている。
うまくいったやり方をチームでどうすると継続できるか？をシェアして考えて掘り下げて身にしていくサイクルにしないとだ。
なお、やると決めたら、チケット切って次のスプリントの一番上に置くことをお勧めします。
そうすれば改善が進まないんですなんてこともないですし。欲張らずに１つでもいいです。やらないよりは。
