VRヘッドセット用のソフトウェア・ビルドが、エレクトロニクス・ワークストリームではすでに実行済みの緊急変更要求を反映していなかった。POはデイリー・ミーティングでこの変更をソフトウェア・チームに伝達しましたが、誰もそれを記録しなかった。今後このような問題を避けるために、PMはどうすれば良い？「バックログ洗練ミーティングの頻度を増やし、レトロスペクティブで変更を記録する。」「次回のイテレーションの前に、チームとプロダクト・オーナーと一緒にプロダクト・バックログの洗練を実施する。」「アドホックのレトロスペクティブを実施し、合意された緊急変更プロセスをチーム憲章に加える。」

→アドホックのレトロスペクティブを実施し、合意された緊急変更プロセスをチーム憲章に加える。

この場合、イテレーティブなアジャイル変更対応は十分なスピードを発揮できていません。アジャイルにおいて継続的改善はレトロスペクティブを通して実現するものであり、ワーク・プロセスはチーム憲章に記載されます。次のイテレーションまで待つと、変更に対応するには遅すぎます。バックログの洗練頻度をさらに増やすと、「作業せずに済む量を最大限に引き上げる」という原則に反します。また、サーバント・リーダーは、チーム・メンバーに即興的なアクションを強制しません。

理由：

• 問題の本質は、緊急の変更要求が記録されず、ソフトウェアに反映されなかったことにあります。
• これは、情報伝達の曖昧さ・記録漏れ・プロセスの不備によって引き起こされています。
• 一度発生した重大なミスに対しては、**アドホックのレトロスペクティブ（緊急の振り返り）**を行い、再発防止策を早急にチームで合意することが重要です。
• さらに、緊急変更への対処プロセスを明文化し、チーム憲章に追加することで、今後の行動基準を明確にできます。

他の選択肢について：

• b. プロダクト・バックログの洗練を実施する
  　→ 定例の作業として重要ですが、今回のような緊急変更の伝達・記録ミスには直接対応できません。
• c. チーム・リーダーに内々でリマインドする
  　→ 個人への責任転嫁に近く、チーム全体でのプロセス改善につながりません。
• d. バックログ洗練ミーティングの頻度を増やし、レトロスペクティブで変更を記録する
  　→ 頻度を上げるだけでは緊急性には対応できず、記録のタイミングも遅れる可能性があります。

PMI提供　クローン問題（ハイブリッド型）5