As an Engineering Leader, one of the most consistently valuable practices I’ve seen in software teams is the retrospective.

Not because retrospectives are “part of Agile.”
Not because Scrum says so.
But because they create something that most teams rarely get in their day-to-day work:

A dedicated space to pause, reflect, and improve together.

The Problem With Most Team Meetings

Think about the typical meetings in a software development team:

• Stand-ups → focused on status updates
• Sprint planning → focused on upcoming work
• Refinement → focused on requirements
• Estimation → focused on sizing
• Sprint review/demo → focused on showcasing delivery

Every meeting has a fixed agenda.

And because of that, many important frustrations never surface.

The developer silently struggling with a painfully slow testing process.
The reviewer overwhelmed by huge AI-generated pull requests.
The engineer frustrated with deployment steps or debugging logs.
The recurring outage everyone has accepted as “normal.”
The team spending too much time in meetings without realizing it.

These problems often remain hidden because there’s no dedicated space to discuss them openly.

That’s where retrospectives become incredibly powerful.

Retrospectives Reveal What Teams Usually Don’t Say

In my experience, retrospectives consistently bring out pain points that otherwise remain invisible.

Sometimes the issues are technical:

• Slow code reviews
• Long testing cycles
• Difficult debugging workflows
• Poor developer experience
• Deployment friction
• Weak observability/logging
• Tooling inefficiencies

Sometimes they are process-related:

• Too many meetings
• Unclear ownership
• Communication gaps
• Slow decision-making
• Delivery bottlenecks

And sometimes they are simply human:

• Frustration
• Fatigue
• Misalignment
• Feeling unheard

These things rarely appear in Jira tickets or sprint metrics directly.
But they heavily impact morale, productivity, and delivery quality.

A Real Example

I once facilitated a retrospective-style discussion for a sibling team after their Engineering Manager had left the company.

That team had rarely done retrospectives before.

What was fascinating was how quickly hidden assumptions surfaced.

One engineer mentioned that testing certain changes could take hours.
Another senior engineer immediately responded that testing should only take minutes and didn’t realize others were struggling.

The team worked together every day; yet they had completely different perceptions of the same workflow.

That single conversation uncovered issues that likely existed for months.

If the team had been running regular retrospectives, these discussions would probably have happened much earlier.

Retrospectives Drive Continuous Improvement

The most valuable retrospectives are not just “complaint sessions.”

They lead to action.

Over time, I’ve seen retrospectives improve:

• Release processes
• Deployment reliability
• Code review quality
• Developer productivity
• Team communication
• Incident handling
• Outage frequency
• Adoption of new tools and practices

They also help teams zoom out and look at broader engineering health indicators:

• DORA metrics
• Lead time
• Cycle time
• Mean time to recovery
• Defect trends
• Team morale
• Operational load

Without retrospectives, teams often stay trapped in delivery mode forever.

They keep shipping.
But they don’t improve how they ship.

Retrospectives Matter Even More in the AI Era

With AI-assisted development becoming common, retrospectives are becoming even more important.

Teams are now adapting to entirely new workflows:

• AI-generated code
• AI code reviews
• Automated suggestions
• Larger pull requests
• Faster delivery expectations

And with those changes come new questions:

• Are AI review comments useful or too verbose?
• Are developers actually reading AI feedback?
• Is AI-generated code harder to review?
• Are reviewers overwhelmed?
• Is quality improving or degrading?

These are not questions a stand-up or planning meeting will solve.

Teams need space to reflect on how new tooling impacts their ways of working.

Retrospectives provide that space.

Retrospective Formats That Have Worked Well

Over time, my teams have experimented with multiple retrospective formats.

1. The Classic “What Went Well / Didn’t Go Well”

Usually done on tools like:

• Confluence
• Miro
• Microsoft Planner

The team collaboratively writes:

• What went well
• What didn’t go well
• What could be improved

Then the moderator discusses each point and captures action items.

This format works especially well for distributed teams because quieter team members often feel more comfortable writing first before speaking.

2. Round-Robin Discussion

A simpler conversational format where each person shares:

• What worked well
• What frustrated them
• What could improve

The facilitator notes recurring themes and action items.

This format feels more personal and works well for mature teams with strong psychological safety.

3. Red / Yellow / Green Health Check

This format focuses on categories such as:

• Code quality
• Deployments
• Testing
• Team collaboration
• Delivery pace
• Technical debt
• Team morale

The team collectively signals whether each area feels:

• Green → healthy
• Yellow → concerning
• Red → problematic

The interesting part is not the colour itself; it’s the discussion that follows.

When someone marks something as red or declining, it opens the door to deeper conversations that otherwise may never happen.

Other Effective Retro Formats

Some additional retrospective formats commonly used across the industry include:

Start / Stop / Continue

• What should we start doing?
• What should we stop doing?
• What should we continue doing?

Mad / Sad / Glad

Focuses on emotional responses to recent events and helps surface team sentiment.

Sailboat Retro

• Wind pushing us forward
• Anchors slowing us down
• Rocks/risks ahead

Great for strategic discussions.

4Ls

• Liked
• Learned
• Lacked
• Longed for

Helpful after major projects or releases.

The Difference Between Teams That Do Retrospectives and Teams That Don’t

Over time, a pattern becomes visible.

Teams that avoid retrospectives often:

• Normalize recurring pain
• Accept inefficient processes
• Repeat the same mistakes
• Build silent frustration
• Lose opportunities for improvement

Whereas teams that consistently run retrospectives tend to:

• Improve incrementally
• Surface issues earlier
• Adapt faster
• Build stronger collaboration
• Create healthier engineering cultures

Retrospectives are not about perfection.

They are about continuous improvement.

Even small action items, repeated consistently over months, can significantly improve team effectiveness and developer happiness.

Final Thoughts

Software teams operate in constantly changing environments:

• New technologies
• New architectures
• New delivery pressures
• New tooling
• New organizational challenges

Without deliberate reflection, teams can easily fall into reactive working patterns.

Retrospectives create a structured pause.

A moment to ask:

• What’s working?
• What’s hurting?
• What should change?
• What should continue?

And in my experience, some of the most impactful engineering improvements don’t start from strategy decks or leadership meetings.

They start from a simple retrospective conversation where someone finally says:

“This has been frustrating us for a while.”