プラクティス名（別名）
オーバーオール・レトロスペクティブ （Scaled Retrospective）
プラクティスの目的・狙い
- 大規模アジャイル（複数チームでの開発）において、チームをまたぐ課題や組織構造/制度に関わる問題解決を図る
どんな時に使うか
- チーム単独では解決できない課題を解消したい
- 他チームにも共通する全体的な課題を解消したい
- チーム間の関係性を改善したい
実施手順
【実施タイミング】各チームのスプリントレトロスペクティブ実施後
【参加者】PO、SM、各チームの代表者、マネージャー（必要に応じて）
- システム全体を様々な角度から議論し、分析する（全体課題の抽出）
- 次スプリントで実施する課題解消のための実験案を検討する（改善策の決定）
- 次回レトロで実験の結果をふりかえり、学習して適応する（継続的改善）
LeSS解説本ではオーバーオールレトロはチームレトロ後に続けて行うと集中力が続かないため、別日に行うことが推奨されています。また改善策をタイムリーに取り込むためには次回プランニング前に済ませておくことが望ましいとされています。
参加者の「各チームの代表者」が誰であるべきかは特に決まりはありません。が、POやSMはもともと参加者になっているため、必然的にDEVの誰か、ということになりそうです。(各チームごとに専属のPOやSMがいる場合はその人が代表者を兼ねる、というケースはあるかもしれませんが）
アレンジ例
- チーム代表者をローテーション制にする
アンチパターン
- 各チームの課題報告に終始してしまい、組織構造といった大枠の問題に目がいかなくなる
- 遅延原因追及の場と化し、心理的安全性が損なわれた結果、何も課題が挙がらなくなる
- チーム全員がオーバーオールレトロに出席する（→参加人数が多くなりすぎて儀式化する）
参考情報
参考書籍
LeSS公式WEBサイト
チーム代表者をローテーションする場合はTKKRTKYさんの実践レポが参考になりそうです。
（素晴らしい記事をありがとうございます！）
こぼれ話（私的コメント）
Nexus（スクラム考案者の一人、Ken Schwaberさんが提唱する大規模アジャイルのフレームワーク）のプラクティスにも「Nexusレトロスペクティブ」という似たものがあります。こちらも目的としては各チームが抱える課題とチーム横断的な全体課題の統合/適応を図ることです。「Nexusレトロスペクティブ」ではレトロを３パートに分け、
（１）チーム代表者が集まって全体課題を特定
（２）各チームごとに分かれてレトロを実施
（３）再びチーム代表者が集まって全体課題を協議
という流れとなります。「オーバーオールレトロスペクティブ」との違いは（１）があるか無いか、という点です。（１）があることでいち早く全体課題を各チームに周知できるものの、ややトップダウン的な色合いが強まるのと、ステップが増えることでフローが重くなるというデメリットがありそうです。
個人的には（１）が無いオーバーオールレトロの方がシンプルで好きです。スクラムはボトムアップの方が良い気がするので。