アジャイルのレトロスペクティブは，主にチームあるいはプロジェクトのレベルで行われる。もし50チーム以上で行う必要があったとしたら，どうなるだろう？ Luke Hohmann氏は，タイムゾーンの異なる数十のチームで大規模なレトロスペクティブを行う方法について，ブログに記事を書いている。その中で氏は，大規模なアジャイル変革プロジェクトにおいて，何がうまくいったか，何に改善が必要か，といったことを見直すために，大規模レトロスペクティブを行った経験を語っている。
InfoQは氏にインタビューして，大規模なレトロスペクティブの実施とデータの解析，そこからのアクションに対するフォローアップについて話を聞いた。
InfoQ: 記事では，多数の参加者による大規模なレトロスペクティブを紹介していますが，"大規模"というのはどのような意味なのでしょうか？
Luke: 複数の地域や時間帯から数百人が参加する，という意味です。"お金が掛かり過ぎて，ひとつの部屋には集められない"，と言い換えてもいいでしょうね！"スケーラブル・エンタープライズ・レトロスペクティブ" では，多数のチームが関与する場合に，企業全体としてパフォーマンスを向上するソリューションを提供しています。
InfoQ: 大規模なレトロスペクティブと，チームあるいはプロジェクトレベルのレトロスペクティブの違いについては，どのような意見をお持ちですか？
Luke: 従来のレトロスペクティブは，関係者の数が多くなると，コスト効率的な面で実施が不可能になります。実施の頻度も違います。単一チームのレトロスペクティブならば各スプリントの終わりか，開発プロダクトのデリバリ時に行うのが普通ですし，プロジェクトのレトロスペクティブはプロジェクトの最後に実施します。一方のエンタープライズ・レトロスペクティブは，組織レベルでの障害の特定と解決に基づいて，それにペースを合わせて実施されます。大規模な組織での組織障害の解決には多くの時間と労力が必要なこともありますから，エンタープライズ・レトロスペクティブは，インパクトは大きいのですが，頻度はそれほど高くないのが一般的です。
InfoQ: 大規模なレトロスペクティブを行うために，"Speed Boat"の練習を選択したのはなぜでしょう？ どのような部分が適しているのですか？
Luke: "Speed Boat"は，障害を特定する上で，オープンエンドで発散的なプロセスを提供するようにデザインされています。レトロスペクティブの題材として理想的なイノベーションゲームです。 障害の種類に関して前提条件はありません。さらに，非常に柔軟性のあるメタファでもあります。このゲームはボートや熱気球，レースカー，飛行機といった，高速移動が可能であって，なおかつ速度を低下させる何らかの要因を持っているものならば，何にでも適用できるのです。
InfoQ: あなたの記事では，大規模な分散型チームがレトロスペクティブを諦める理由として，"改善できることの限界にぶつかる"ため，と述べられていますね。それについて詳しく説明して頂けますか？
Luke: 例えば，スクラムチームひとつの小さな新興企業を考えてみましょう。そのチームが，ソースコード管理システムを別のものに移行する要求について，レトロスペクティブで確認するとします。必要な意思決定者，決定によって影響を受ける人たち，最終的な判断を行う意思決定者がすべて同じ部屋にいますから，その場で決めることができます。
では，47のスクラムチーム(約300名の開発者)からなる，大規模で成熟した開発組織をこれと比較してみましょう。これらスクラムチーム中の28チームはソースコード管理システムに問題を感じていて，変更を望んでいるとします。これはチームレベルの意思決定ではなく，企業としての意思決定になります。さらに検討の結果として，組織がソースコードシステムの移行を決定したと仮定しましょう。100人単位の開発者が使用するソースコード管理システムの変更は，簡単にできることではありません。綿密な計画と慎重な管理を要する一大プロジェクトです。技術的な問題はもちろんのこと，運用中のシステムのバグ修正に必要なバージョンヒストリを維持しなければなりません。新システムに向けた技術者のトレーニングも必要です。インテグレーションやテストの自動システムの変更なども必要かも知れません。
InfoQ: 大規模レトロスペクティブの実施にオンラインゲームを使用していますが，その理由を教えてください。
Luke: オンラインゲームは低コストですし，結果がすぐに分かるからです。関係するチームが都合のよい時間にレトロスペクティブを実施可能ですから，データ分析の面でも優れています。オンラインという形式は，内向的な人たちや，主要言語以外を母国語とする国の人たちの考えを表現したり，把握したりするにも好都合です。
オンラインで行うことで，各チームがチームとしての体制を保つことができます。大規模な組織における組織的技術の単位は，常にチームなのです。
オンラインで行うということは，複数の進行役が関与できるということでもあります。それによって進行役によるバイアスが低減されますから，さらによい結果を得ることができます。
InfoQ: 多数のチームからのデータを解析して，実行すべき行動を決定するにはどうすればよいのでしょう？
Luke: 私たちがいつも行っているデータ解析方法を紹介しましょう。
ステップ１: 各チームがゲームをプレーします。
ステップ２: 各チームの結果をひとつのスプレッドシートにダウンロードします。これは簡単で，それぞれの進行役がゲーム結果をダウンロードして，共通のスプレッドシートにそれをアップロードするだけです。
ステップ３: 人手/プロセス/テクノロジを使って，コントロールの範囲によって結果をコード化します。ゲームを速やかに進行するためには大勢で行った方がよいのですが，スピードと一貫性の面から，私たちとしては２～３人のチームでこの作業を行うことを推奨しています。
ゲーム内のすべてのアイテムをコード化します。Speed Boatを使っているなら，錨やプロペラなどすべて，ということです！
私たちはアイテムを，"主(Primary)"となる人/プロセス/技術と，省略可能な"従(Secondary)"である人/プロセス/技術でコード化する方法を推奨しています。例えば，"PO(プロジェクトオーナ)がレビューミーティングに出席しない" というのであれば人が"主"でプロセスが"従"，"GitHubに乗り換えるべきだ"というのは技術が"主"，といった具合にコード化するのです。
その次に私たちが推奨するのは，あらゆる障害に対処する上で，チームが備えている理解度を評価するために，Diana Larsen氏の円とスープ(Circles and Soups)分類法を利用することです。
- チーム：これはチームが対処すべき問題です。 例えば"POがレビューミーティングに出席しない"という問題に対しては，チームとして対処する必要があります。
- プロダクト/グループ： チームでは対処できない，プロダクトあるいはグループのスコープにある問題です。
- エンタープライズ: 企業としての協調的な努力を要する問題です。GitHubへの移行などは，企業内のすべてのグループに影響を与えます。このような問題は，企業プロジェクトとなる可能性を慎重に評価して，他の影響の大きなプロジェクトと比較する必要があります。
根本的な問題を特定する上では，オンラインチャットのログが貴重な資料になります。
ゲームプレイに知らず知らず入り込んでくる，さまざまな種類のバイアスを見つけ出すため，解析の範囲を拡げることもあります。結果に影響を与えそうなバイアスの例をいくつか紹介しましょう。
自尊心の高い人々[チーム]内には特に，ネガティブな特性よりもポジティブな特性を事実として評価するという，肯定的なバイアスが浸透する傾向があります。チームがプロペラを識別するように指示された場合などに，このようなことが起こります。これを受け取ると，プロペラを探す代わりに "多分できるでしょう"とか，"できるはずです"といったような，向上心のあるログをチャットすることになります。
バイアスの例は，組織の一部(60チーム中20チームのように)だけがプレーしている場合や，１種類のチームだけが関与する場合に見られます。これを避けるには，少なくとも90%のチームの参加を目標とするべきでしょう。
メソッドや質問のバイアスは，参加者を不適切な回答に導く可能性があります。オープンエンドを維持することによって，Speed Boatなどゲームのメソッドと質問のバイアスを最小化します。
LDTR(Large and Distrbuted Team Retrospective)の責任者には，あらゆる潜在的なバイアスを考慮しておくとともに，調査報告における潜在的なバイアスの評価の実施を期待したいと思います。
ステップ４: 結果を解析して，パターンを特定します。結果がデジタルデータであることの大きなメリットのひとつが，RやQlikviewといった高度なツールを使ってデータ分析できる点です。上位リーダに対して，組織レベルでの障害の存在を認めるように説得しようとするなら，このような結果の視覚化は絶対に必要です！
ステップ５: パターンをプロジェクト化すべきテーマにまとめ上げます。このステップには１週間ほどかかる化も知れません。でも，それでよいのです！あなたは今，信じがたいほどインパクトの大きなチャンスを得ようとしているのです。そのために投資する時間は，最高の結果として戻ってくるでしょう。
ステップ６: プロジェクトが選択されます。プロジェクトの数が少なければ，単にそれらを選択します。あるいはプロジェクトの数が多ければ，"Buy a Feature" (優先順位を付けるためのイノベーションゲーム)を使うのもよいでしょう。
InfoQ: 大規模レトロスペクティブで生み出されたアクションをフォローアップするには，どうすればよいのでしょう？
Luke: アジャイルやリーン，かんばんなどを使用している組織は，透明性の価値を尊重していると私は思います。組織レベルの障害を認識し，それらを解決するプロジェクトを発足させた後は，それらが実施される進捗の状況を会社全体に可視化することで，それを示すのです。企業レベルの障害は必然的と言ってよいほど，個人やチームの作業方法に影響を与えますから，ほとんどの場合において，これは非常に望ましいことです。
InfoQ: 組織で何がうまくいっていて，何に改善が必要なのかを見つけ出す方法として，レトロスペクティブ以外に方法はあるのでしょうか？それらはどのような時に使うのでしょう？
Luke: 改善の機会を特定する方法として，一部の企業では匿名アンケートを活用しています。作業者がお互いに協力することや，アジャイルを採用することを拒むようであれば，Speed Boatゲームを何度が実施した上で調査するとよいでしょう。