チームは時にレトロスペクティブの省略を考える。時間的なプレッシャを感じているとき，直接的なメリットが感じられないときなどだ。彼らは自問自答する – レトロスペクティブを続ける必要があるのだろうか？ しかしアジャイルのレトロスペクティブは，チームが継続的に学び，進歩するために必要なものだ。チームの成熟のためにも，継続するだけの十分な理由がある。
Dave Moran氏は最近，"レトロスペクティブを省略できないだろうか？" という質問を耳にすることが多いと言う。そういう場合，氏は次のように提案する：
チームに向かって，アジャイルを行うことの意味を問いかけてください。こういった状況では，アジャイル憲章に立ち返るようにチームを導くことが有効です。原則のひとつでも述べているように，"定期的に効率を改善する方法について検討し，それに従って自らの行動を調整，適応させる" 必要があります。
氏の経験によれは，組織がアジャイルを採用することで得られる改善とは，変化を行うための方法なのだ。
チームにとってレトロスペクティブとは，立ち止まり，振り返り，学習するチャンスなのです。レトロスペクティブは，継続的改善をサポートするためにスクラムに組み込まれた重要なメカニズムであり，非アジャイル組織の多くには実現困難な概念です。非アジャイル環境における改善には継続性がなく，通常は中央統治的なプラクティスとして現れます。考え得るすべてのシナリオをカバーするように設計されることで，すでに肥大化している開発プロセスの上に，さらに付け加えられるものなのです。
氏はアジャイルで継続的改善をサポートすることの重要性を強調するとともに，レトロスペクティブのようなアジャイルプラクティスの採用が与える影響について説明する。変化を起こすために組織がこれまで用いてきたアプローチに対比して，アジャイルのプラクティスとはどのような意味を持つのだろうか：
私たちは今，従来のタスクと機能の組み合わせに関わるシンプルで直接的，効果的なアプローチを維持する一方で，本質的でないオーバーヘッドをはぎ取ろうとしています。デリバリを – 品質を保ちながら – 加速するためです。ほとんどの組織が(今でも)必要と信じて疑わないものをオーバーヘッドとして排除するとなれば，彼らの懸念を打ち消すだけの何かが必要です。レトロスペクティブを通じた継続的改善は，アジャイルチームが彼らの生産性と効果性に注意を払っている，という保証を与えてくれます。アジャイルに対する懸念を打ち消して，既存のアプローチを凌駕するアジャイル実践の有効性を実現する手段を提供します – それこそが，私たちが実証すべきものなのです。
James Harvey氏は Never Underestimate the Importance of Continuous Improvement という記事で，チームがレトロスペクティブを省略することによって，結果的に生産性の低下というリスクが生じると説明している。
アジャイルチームでの私の経験から，スプリントのレトロスペクティブミーティングが省略されるのは，チームが十分な効率性を達成した場合です。"さあ，作業はもう十分にうまくいったんだから，悪いところを探す必要なんて何もないさ。そうだろう？"，という具合に。成功体験にとらわれることの危険性が現実になり始めるのは，まさにこんな時です。間違ったことはしていなくても，チームはやがてベロシティ，効率，気力といったものを失い，何ら努力をしなくても作業は完了すると考えるようなスランプに陥ってしまうことでしょう。
レトロスペクティブを続けることはチームにとって価値がある，というのが氏の意見だ。
改善すべき課題は多くなりますが，それを達成することで得られる成果もまた，途方もなく膨れ上がるのです。
Brian Copeland氏は Agile vs Fragile: Retrospective Look Forward と題したブログ記事で，"脆弱(Fragile)"なチーム，すなわち "プロジェクトの貧弱なデリバリ実績の言い訳としてアジャイルを利用するチーム" が，レトロスペクティブをどのように見ているか説明している。
ここは多くのチームがつまずく場所のひとつです。彼らはレトロスペクティブの時間を取りません。価値を理解していないからです。次の開発スプリントのために費やされるべき時間を無駄遣いしている，と思っているのです。
脆弱なチームでもセッションから学ぶことはあるでしょう。しかしそれは，単にアジャイルのガイドにそうするべきだと書いてあるからに過ぎません。真剣にはとらえていませんし，その結果もほとんど意味を持ちません。セッションが，スプリントの失敗は自分たちのせいではない，他のチームのやり方が違っていれば成功したはずだ，などと証明するために全員がベストを尽くす "非難ゲーム" になっているのです。
脆弱なチームにおけるレトロスペクティブの問題は，アジャイルを実践しているチームにも無縁ではない。
このようなチームには，彼らの選択した方法論が問題なのではない，という認識がありません。成功を決定付けるのは，その方法論の活用段階において彼らが備えていた規律にある，ということが理解できていないのです。ある方法論を採用しても，その原則を完全に支持できないのであれば，それは予測不可能な矛盾した結果へとつながります。まさしく "脆弱(Fragile)" なのです。
Justin Carmony氏は，自身のチームがレトロスペクティブから得た結果について，The Catalyst for Agile Development: Sprint Retrospective と題したブログ記事に書いている。氏らがレトロスペクティブを始める前の状況を説明することろから，その記事は始まる。
(...) 私がDesert Newsチームに参加してマネージメントを始めた頃，アジャイルプロセスはすでに実施されていました: スプリント，見積，スタンドアップ，プランニングセッション，等です。ほとんどの部分はうまくいっていましたが，チームとして次のレベルの生産性を達成するのに苦戦している状況でした。いつも何かが欠けているように感じていたので，いろいろなことを試していました。１週間のスプリントか２週間か，ミーティングをいつ開くか，誰が誰に関与しているか，等々。しかし何を試してみても，単に周囲を混乱させているだけにしか思えませんでした。次のレベルの生産性を達成することはできなかったのです。
氏らはスプリント計画セッションで，スプリントのレトロスペクティブを導入した。
私たちはスプリント計画ミーティングを隔週で実施して，先回のスプリントをレトロスペクティブに反映するようにしました。(….) うまくいったこと，いかなかったこと，変更したいと思っていることの一覧です。前回のスプリントの一覧を見てその出来具合を確認し，それらを確実に行うための改善に着手するのです。毎週毎週，このような時間を確保してプロセスを修正し，改善すべきことを確認しています。
10回のレトロスペクティブを行った後で氏らは，それがチームの生産性，作業の方法，納期に与えた結果について確認した。
チームのベロシティは倍増しました。
このプロセスを始めた頃の私たちは，バックログや未定義のタスクといった大きな問題に取り組んでいました。それらが解決すると，次には，プロセスの進行を支援する他のことが気になり始めました。しかしながら，私たちがプロセスを定期的に繰り返していなければ，変更すべきこれらのことに気付くことはなかったでしょう。
増加したのはベロシティだけではありません。納期の遵守率もずっとよくなりました。機能に関する意思決定も，それまでよりずっと自信を持ってできるようになりました。新たな機能が提示された場合，納期に対する影響を見積もって，どのようなアクションをコースとして選択するか決められるようになったのです。
氏のアドバイス: "レトロスペクティブを行っていないのなら，一度試してみてください。すでに行っているなら，まわりにそれを広めましょう。”
レトロスペクティブはアジャイル開発の可能性を解き放つものだ，と私は心から思っています。私たちはプロセスを右往左往する状態を脱して，イテレーションを整然と行えるようになりました。私が残念に思うのは，アジャイルプロセスの話題を耳にすることがあっても，"レトロスペクティブ"の実践に関してはまったく聞いたことのない点です。見積やバックログ，スプリント，ベロシティ，あるいは中心的原則に関してならば耳にしますが，アジャイルプロセス全体を次のレベルに引き上げる上で重要な促進役になるレトロスペクティブについては，ほとんど注意が払われていないように思うのです。