Hiren Doshi氏はPractice Agile Software Developmentのブログ記事に匿名振り返りについて書いている。チームのフィードバックを最大化する方法だ。
Wikipediaによれば振り返りとは、
プロジェクトチームが開催するミーティング。プロジェクトやプロセス(イテレーション)の終わりに開催される。プロジェクトや振り返り対象の期間の中で何が成功したか、何が改善できたか、成功や改善を将来のイテレーションやプロジェクトでどのように役立てるのかを議論する。
Doshi氏によれば、組織のオープンさと透明性に関わらす、他人や同僚、マネジメントの前で話すのが苦手な人がいる。
チームに本当の刺激を与えるには、次のようなモデルを使うのが良い、と氏は主張する。
- メンバの全員が参加する。
- 集めたデータは完全に匿名。書き手が特定できないようにする。
- 各メンバにポストイットを配布。良かった点、改善が必要な点を質問する。
- ポストイットを折り畳んで、空の箱に入れてもらう。
- 全員が終わったら、箱の中身を混ぜて、各ポストイットを取り上げる。
- 誰かにポストイットの情報の記録係を頼む。ポストイットに書かれた情報を読み上げ、記録し、ポストイットをゴミ箱に捨てる。
- すべてのデータが集まったら、チームで分類して各分類のデータをつなぎ合わせて情報を生成する。
- 最後に、各カテゴリごとにアクションプランを定義する。
Doshi氏は以下のように結論付けている。
ほとんどの場合、複数回実施する必要があるでしょう。しかし、少しずつ改善がされていることを確かに感じることができるはずです。これが匿名振り返りの効果なのです。
Esther Derby氏とDiana Larsen氏はAgile Retrospectives Making Good Teams Greatという本で振り返りを実施するときに従うべきモデルについて提案している。
- ステージをセットする。
- データを集める。
- 知見を生み出す。
- 何をするか決める。
- 振り返りを終える。
この本では、上記の各ステップの実施方法と特定の状況でいかにしてその方法を使うかが書かれている。
人前で話すのが苦手な人を対象にして、彼らはひとつのシンプルなチャレンジをアドバイスしている。そのような人たちにはミーティングの最初の5分で自分の名前を言うように指示しておくのだ。そうすれば、"驚いた。よく話せる!"という反応が得られるだろう。
また、ある種の質問を避けることもアドバイスしている。
エンジニアと仕事をする場合、彼らは自分の気持ちを表現したくないかもしれません。なので、振り返りでは、どんな気持ちを抱いたかは聞かないようにします。
ミニブックGetting Value out of Agile Retrospectives - A Toolbox of Retrospective Exercisesでは、ミーティングで使えるグループエクササイズが紹介されている。著者らによれば、"振り返りで有効に活用できる"そうだ。
Constellationと呼ばれるエクササイズでは、参加者は話す必要はない。ファシリテーターの質問に従って動くだけだ。チームに引っ込み事案な人、シャイな人がいたとしても、このやり方ならチームにはそのような人がいるということ自体を明らかにできる。