Retrospective on retrospectives: do you even need retros?

What if your team would address issues immediately instead of waiting for a retro?
How effective is it to identify action points that end up not being chased?
When do you celebrate success?

The old saying "hindsight is 20/20" is usually used when someone should've known better. It has a pretty negative or condescending tone to it, but for agile software development, it can be valuable to apply some hindsight when preparing for the next iteration of your product.

Indeed, reflecting on past performance and analyzing what worked and what did not can enable you improve over time, but many teams end up going through the motions every sprint, ticking off a bingo card.

In this episode, we debate among each other of our perceived effectiveness of periodic retros.

What do you think? Do you feel retrospectives are a vital part of making teams more and more effective or are they redundant and you should just address issues as they come up?