エンジニア的なネタを毎週書くブログ

東京でWebサービスの開発をしています 【英語版やってみました】http://taichiw-e.hatenablog.com/

チーム異動があって、「ふりかえり」が自分の中では一番大事だと気づいた話

2月の半ばに組織改編があり、新しいチームにリーダーとして異動しました。新しい環境で試行錯誤する中で、自分がチームビルディングにおいて大切に思っているものが見えてきたので、それを書き残しておきたいと思います。
数回に分けて書く予定ですが、そう宣言しておいて続いた試しがこのブログでは無い…

ふりかえりのためにタイムボックスをセットした

異動してチームメンバーに初めにさせてもらったことは、二週間のスプリント切りでした。

今日から2週間で一旦区切らせてください、というお願いです。

アジャイルな開発」をするため?  多分違います。
計画を立てて実施しきるため?  それも違います。
理由は一つ。「ふりかえりをするため」です。

私は、チームが自分たちのやり方やスキル、チーム力を高めていくために、短いサイクルでの定期的なふりかえりが、最も大切と考えています。
ですので、私の新しいチームのメンバーには、定期的な間隔でふりかえりがあること、そしてその場では、自分たちの問題を自分たちで発見し、自分たちで解決までのプロセスを考えてよいことを知って欲しかったのです。
そのためのスプリント切りでした。

一方で、最初のスプリントの”計画は”、ややゆるめに、「今までの流れで、もともと、むこう2週間でやろうと思っていたことを、この2週間でやってください」と伝えるに止めました。
今回の異動では、もともと存在していたチーム・案件に、私一人が新参として入った状況です。一番プロダクトのことも案件のことも分かっていない私があーだこーだ言うよりも、基本的にはもともとみなさんがやられていたやり方を継続してもらう方がいいと考えました。

たくさんKeepやProblemが出てきたふりかえり

ふりかえりミーティングでは、「全員に参加」してもらうために、Keepと Problemのパートでは順番に一人一人思っていることをあげてもらう手法を取りました。また、私が強めのファシリテーションをし、あげてもらったものに対して深掘りすることもしました。
「○○ができてよかった」→「それができた要因ってなんでしょう?」
「○○で困った」→「本質的には何に困ってたんだろ?」「そういうことが起こった要因はなんだろう?」
という具合です。

嬉しかったのが、みなさん、たくさんのKeepやTryを上げてくれたことでした。初回は一人当たり、2つ以上のKeepとProblemが上がったような気がします。
私が異動してから5回ほどふりかえりを行いましたが、今でもこの傾向は続いていて、嬉しい限りです。

また、ProblemからTryに落とし込む際も、真剣に考えてアイディアを出してくださっている印象があります。

このチームはこれからどんどん、自分たちを自分たちで良くしていって、強いチームになっていくと思います。