いまさら「Project Retrospectives: A Handbook for Team Reviews」を読む

同僚と「アジャイルレトロスペクティブズ　強いチームを育てる「ふりかえり」の手引き」の話をしていたところ、同書で紹介されていた類書「Project Retrospectives: A Handbook for Team Reviews (Dorset House eBooks) (English Edition)」に気が付いた（自分が読んだ時には気づかなかったなぁ）。未翻訳だけど、そういえばO'reillyで原著が読めるので、興味の向くままに読んでみた。2001年の本である。

Project Retrospectives: A Handbook for Team Reviews (Dorset House eBooks) (English Edition)

作者:Kerth Norman L.
発売日: 2013/07/15
メディア: Kindle版

そういえば平鍋さんのブログでも紹介されていた（自分、重要さに気づくのが15年ほど遅い）。

プロジェクトの「ふりかえり」 -- Retrospectives by Norm Kerth：An Agile Way：オルタナティブ・ブログ

全体的な感想

本書の重要な点は、アジャイル開発の文脈と切り離されている点である。よって本書で扱う「ふりかえり」は反復的なものではない。でもみんな今必要なのは、これでしょ？
著者Norman Kerth氏のふりかえりに関するゴールデンルールは忘れないようにしたい。

カースの最優先事項
今日見つけたものが何であれ、チームの全員が、その時点でわかっていたことやスキルおよび能力、利用可能なリソースを余すことなく使って、置かれた状況下でベストを尽くした、ということを疑ってはならない

加えて上記ほどはピックアップされていないけど、ケーススタディ他で取り上げられているこのルールも重要だと思う「参加者の誰かを犠牲にするジョークは言ってはならない」
本書で扱われる「ポストモーテム」はSREの文脈における（インシデントに対する）ポストモーテムとは異なる点には留意をしたほうが良さそう
残念ながら本書のサポートサイトである www.retrospectives.com はクローズされている。というか著者のKerth氏は99年の自動車事故により引退されているようだ。残念で仕方ない
- Norm Kerth's Situation
PMBOKベースのプロジェクトマネジメント方法論にも「終結」プロセスっていうのはあるけれど、私は本書のアプローチのほうが良いと思う。

Project Retrospectives: A Handbook for Team Reviews 各章の感想

序文

だいぶ良い出だし。惚れた。

そうら、クマくんが、二階からおりてきますよ。バタン・バタン、バタン・バタン、頭を階段にぶつけながら、クリストファー・ロビンのあとについてね。二階からおりてくるのに、クマくんは、こんなおりかたっきり知らないのです。もっとも、ときには、かんがえることもあるのです。このバタン・バタンをちょっとやめて、かんがえてみさえしたら、ほんとは、またべつなおりかたがあるんじゃないかな……とね。
A.A.ミルン「クマのプーさん」

(中略) ミルンの言葉を読んでいるとき、ミルンが説明している世界と私たち自身のクレイジーなソフトウェア開発の世界の類似点に驚嘆しています。ソフトウェア開発者として、私たちはプロジェクトごとに毎日頭をぶつけています。少し時間をとって別の方法を考えれば、もっと良い方法が見つかると思います。
Project Retrospectives: A Handbook for Team Reviews (Dorset House eBooks) (English Edition)

本書を通じて読者はプロジェクトの最後に「特別な儀式：ふりかえり」を行い、立ち止まって考えることができるようになる。
ソフトウェア開発の分野は急速に変化しているため、作業慣行を継続的に見直す必要がある。振り返りは、ソフトウェアプロセスの改善に役立つ。
プロジェクトが失敗した場合、ふりかえりによってプロジェクトメンバーは失敗から学び、それを超えて進むことができる。
ふりかえりは、参加者の学習、成長、成熟を促進する。

第1章：ふりかえりの紹介

プロジェクトで反省をするということは「自然な行為」ではない。よって行為を形式化し、儀式化し、意識的に実施する必要がある。
ふりかえりでは心理的安全性が重要である。
ふりかえりを成功させるためにはファシリテーションが重要である。

第2章：ふりかえりの解剖学／ケーススタディ

本章では本書が提起するふりかえりの流れがストーリーとして共有される。かなり興味深い。

第3章：ふりかえりのエンジニアリング／選択について

前回のふりかえりのテンプレートをコピーするほうが、新たにふりかえりを設計するより楽だが、過去のテンプレートは現在の状況に適合するとは限らない。
ふりかえりは、環境条件とチームのダイナミクスにあわせて設計すべきである。
考慮すべき事項
- 目的
- 組織文化（健康状態）
- ふりかえりをリードするスキルを有しているか
- 参加者
- 実施場所
- 実施時期
- 期間（効果的なふりかえりを行うのであれば3日を要する）

第4章：ふりかえりのアイデアを組織に売り込む方法（かなり意訳。原題はSelling a Retrospective）

組織やプロジェクトをとりまく環境によってアプローチは異なる
第1セグメント：改善が習慣化された組織
- ふりかえりは改善施策を補完する、と説明すればよかろう
第2セグメント：トラブルや失敗に対する対策を考えている組織
- トラブルを防止する方法を発見することをコミットする
- 対応しなければトラブルは再発する、と伝える
第3セグメント：プロセスを変える気はない
- 長期的なマーケティングを実施するしかない
- 個別チームが第1もしくは第2セグメントするように後押しする

第5章：ふりかえりの準備

まず、マネージャと初回セッションを実施する
コミュニケーションマップを作る（マネージャにも手伝ってもらう）
- プロジェクトの略語やチーム名称などについても確認する
メトリクスを収集しておく（スケジュール、コスト、品質）
構成管理データを収集しておく（LOC、etc）
バグ管理システムのデータを収集しておく
参加者を招集する
チェックリストを用いて設備を確認する

第6章：ふりかえりで使うエクササイズ集

準備に関するエクササイズ
- Introduction
- I'm Too Busy
- Define Success
- Create Safety
過去をふりかえるエクササイズ
- Artifact Contest
- Develop a Time Line
- Emotions Seismograph
- Offer Appreciations
- Passive Analogy
- Session Without Managers
- Repair Damage Through Play
未来について考えるエクササイズ
- Cross-Affiniy Teams
- Making the Magic Happen
- Change the Paper
- Closing the Retrospective