Two Hands on the Wheel
Your team is probably wasting the most powerful tool in agile software development.
There’s this metaphor that’s stuck with me for years: when you’re driving a car, you don’t just aim it in a direction and let it go. Instead, you’re constantly adjusting at the micro level—holding the wheel, turning it a micrometer to the left or to the right to make sure you’re on track.
This metaphor applies to a lot of things, but especially to software engineering. And the most concrete example of this in agile software development is the retrospective.
The Most Undervalued Ritual
I’ve long been an advocate for retros as the most important agile ritual—more so than standups or backlog groomings. Here’s why: standups keep you informed about today’s work. Backlog grooming ensures you’re building the right features. But it’s the retrospective that offers the team a collective avenue for ensuring you’re moving in the right direction as a team.
Retros are where members get a safe space to voice their opinions and share ideas, get feedback on those ideas, and actually put them into action through recurring kaizens (continuous improvements). They’re where you talk about the things that don’t fit neatly into a standup: the communication breakdown that cost you three days, the deployment process that’s slowly killing morale, the junior developer who needs more pairing time but doesn’t want to speak up in front of everyone.
What I’ve Seen Go Wrong
So often in my career, I’ve seen teams devalue retrospectives. They only do them at the end of a project, or at the end of a fiscal quarter. I get it—retros can feel like “just another meeting,” especially when they’re run poorly or devolve into unproductive venting sessions. Teams think they’re saving time by doing them less frequently.
But in my opinion, that’s way too late. By the time you’re doing a quarterly retro, you’ve already built three months of technical debt, burned out half your team, and shipped features nobody wanted.
The Cost of Infrequent Course Corrections
To go back to the driving metaphor: you wouldn’t set your vehicle in a direction and then come back to check once you think you should’ve reached your destination, only to find out that you missed your exit three hours ago. That would be absurd.
Yet that’s exactly what teams do when they skip regular retros. They work heads-down for months, assuming they’re on the right path, only to discover they’ve been building in the wrong direction, using processes that frustrate everyone, and missing opportunities to improve along the way.
I’ve watched this play out firsthand. One team I worked with went six weeks without a retro because they were “too busy with the release.” By the time we finally sat down together, tensions were high, the deployment pipeline was a mess, and three people were quietly interviewing elsewhere. If we’d been checking in every two weeks, we could have caught and fixed those issues when they were small.
A Better Way: The Asynchronous Retrospective
Here’s where I’ve been experimenting lately, and I think it solves a lot of the problems with traditional retros.
Instead of blocking 90 minutes on everyone’s calendar every two weeks, I’ve been running what I call asynchronous retrospectives. Using a tool like Figma (or Miro, or even a shared doc), we spin up a traditional retro board and leave it open constantly throughout the sprint. Team members can jump in ad hoc whenever they want and provide feedback—just like they would during the opening 10 minutes of a traditional synchronous retrospective.
This approach has several advantages:
It amortizes the cost of the retro over the entire iteration. Instead of context-switching everyone into a meeting at once, people can contribute when it’s convenient—right after they encounter something worth noting. The feedback is fresher, more specific, and doesn’t require anyone to remember what frustrated them two weeks ago.
It enables more candid, anonymous feedback. Even in psychologically safe environments, some people are more comfortable writing than speaking up in a room. The async format gives everyone equal voice, regardless of whether they’re introverted, remote, or just need time to articulate their thoughts.
It allows for faster reaction. We don’t have to wait for the next scheduled retro to propose changes. We can do kaizens constantly through this approach. When someone drops a piece of feedback into the board, discussions can happen in Slack to refine what a kaizen looks like in response. Small improvements can ship within days, not weeks.
It’s easier to coordinate. No more “sorry, I have a conflict” or “can we move it 30 minutes earlier?” The board is always there. You contribute when you can.
I’ve found this to be much more effective than a traditional, all-hands synchronous retrospective. That said, we do still have a brief sync every two weeks—maybe 30 minutes—to review the async board together, discuss themes, and commit to specific action items. But the heavy lifting happens throughout the sprint, not in one exhausting session.
Keep Both Hands on the Wheel
Whether you go synchronous, asynchronous, or hybrid, the key is this: you need to be doing retrospectives constantly. This is what it means to have both hands on the wheel in software development.
The goal isn’t to have a perfect process. The goal is to constantly adjust your trajectory. A small course correction today prevents a major detour tomorrow.
Your Turn
When’s your next retrospective scheduled? If the answer is “I don’t know” or “not for a while,” that’s your first problem to solve.
And if you’re doing traditional retros but finding them draining or ineffective, consider trying an async approach. Spin up a board, share it with your team, and see what happens when you give people the freedom to contribute on their own time.
Because if you’re not constantly checking whether you’re pointed in the right direction, building the right things in the right way, you’re not really driving—you’re just hoping you end up somewhere good.
Keep both hands on the wheel.