Marc Andreessen recently said something that stopped me in my tracks.
In a conversation with David Senra on the Founders Podcast, Andreessen shared the most surprising thing he learned from studying 400 biographies of history’s greatest entrepreneurs: they had little to no introspection.
Sam Walton didn’t wake up analyzing what went wrong yesterday. He woke up and opened another Walmart. Thomas Edison didn’t run retrospectives on his failed experiments. He just ran the next one. The builders who shaped our world didn’t spend their energy looking backwards — they just kept moving forward.
As a Senior Scrum Master with over 25 years in IT, that hit different. Because I’ve spent a significant chunk of my career facilitating the very thing Andreessen is questioning: the retrospective.
The Sacred Cow of Agile
If you’ve spent any time in Agile, you know the retrospective is untouchable. It’s baked into the Scrum Guide. It’s one of the five Scrum events. Question its value in a room full of Agilists and you’ll get looks like you just insulted someone’s family.
The idea is simple and, on paper, beautiful: at the end of every sprint, the team reflects on what went well, what didn’t, and what to improve. Continuous improvement. Inspect and adapt. The heartbeat of Agile.
But here’s the uncomfortable question nobody asks: Is it actually working?
The Retrospective Problem Nobody Talks About
I’ve facilitated hundreds of retrospectives across financial services, insurance, staffing, and tech. Here’s what I’ve seen over and over:
The same complaints, different sticky notes. Teams surface the same issues sprint after sprint. “Communication needs to improve.” “We need better requirements.” “Too many meetings.” Sound familiar? These aren’t insights — they’re a broken record.
Learned helplessness. When teams repeatedly identify problems they can’t fix — organizational dysfunction, leadership decisions, tooling limitations — the retro becomes a venting session. People leave feeling worse, not better.
Retrospective theater. The team goes through the motions because Scrum says they have to. They generate action items that nobody follows up on. Two weeks later, they do it again. It’s compliance masquerading as improvement.
The dwelling trap. This is the big one. Some teams spend so much energy analyzing what went wrong that they create a culture of blame and anxiety rather than one of momentum and execution. They’re not improving — they’re ruminating.
Stuart Watson captured this frustration perfectly in a response to the Andreessen clip: “It drives me nuts when so many orgs and leaders want to do ‘retrospectives’ and ‘lessons learned’ every 5 minutes. I just want to look forward too.”
He’s not alone. That sentiment is shared by more people than the Agile community wants to admit.
The Andreessen Argument: Zero Introspection
Andreessen’s point goes deeper than just questioning meetings. He argues that introspection itself is a modern invention — a product of early 20th century Freudian psychology that taught people to look inward, feel guilt, and dwell in the past.
For 400 years before that? People just did things.
The personality that builds empires is not the same personality that sits around quietly questioning itself. The Waltons, Edisons, and Carnegies of the world had a bias toward action so strong that looking backwards simply didn’t compute.
Now, I’m not saying we should all adopt the mindset of 19th century industrialists. But there’s a kernel of truth here that the Agile world needs to wrestle with: there’s a real cost to over-reflection.
Every hour spent in a retrospective is an hour not spent building. Every ounce of mental energy spent analyzing last sprint’s failures is energy not directed at this sprint’s possibilities. At some point, the introspection becomes the obstacle.
So Should We Kill Retrospectives?
No. And this is where I break from the hot take.
Here’s what 25 years has taught me: the retrospective isn’t the problem. The way we do retrospectives is the problem.
The best retrospectives I’ve ever facilitated shared three things:
1. They Were Short and Forward-Looking
Fifteen minutes, not ninety. The question wasn’t “what went wrong?” but “what’s the one thing we’re changing next sprint?” One thing. Not a laundry list. One actionable change that the team owns and can actually implement.
2. They Led to Immediate Action
If a retro generates an action item that sits in a backlog for three sprints, it was worthless. The best teams implement the change the next day. The retro is a decision point, not a discussion forum.
3. They Knew When to Skip
This is the part that makes Scrum purists uncomfortable: sometimes the best retrospective is no retrospective. If the team is in flow, shipping value, and morale is high — why interrupt that momentum to look for problems? Not every sprint needs a post-mortem.
The Scrum Guide says the retrospective “concludes the Sprint.” It doesn’t say it needs to be a 90-minute deep-dive into the team’s collective psyche.
The Real Framework: Reflect Quickly, Then Move
The answer isn’t Andreessen’s zero introspection. And it isn’t the Agile industry’s mandatory two-week therapy session. It’s somewhere in between.
The best teams I’ve worked with operate like great athletes. A basketball player who misses a shot doesn’t stop the game to analyze their form. They make a mental note and take the next shot. The film review happens later, it’s focused, and it’s brief.
Here’s my framework for teams that want to move forward without losing the feedback loop:
- Daily micro-corrections over biweekly retrospectives. If something goes wrong Tuesday, fix it Wednesday. Don’t wait two weeks to talk about it.
- Action over analysis. If you can name the problem, you probably already know the fix. Do the fix. Skip the meeting.
- Retrospectives as a circuit breaker, not a ritual. Run them when something genuinely went wrong or when the team asks for one. Not because the calendar says so.
- Time-box ruthlessly. If you do run a retro, 15-20 minutes max. One action item. Move on.
What Would Sam Walton Do?
I keep coming back to Andreessen’s example. Sam Walton opened 8,000+ stores. He didn’t do it by looking backwards. He did it by waking up every morning obsessed with the next one.
Your team probably isn’t building Walmart. But the principle scales down perfectly: momentum creates more value than reflection.
The next time you’re setting up a retrospective, ask yourself honestly: Is this going to make my team better? Or is this just something we do because we’ve always done it?
If the answer is the latter, maybe it’s time to just move forward.
Reggie Hillery is a Senior Scrum Master and Agile Coach with 25+ years in IT across financial services, insurance, and staffing. He holds SAFe, CSM, and ICAgile coaching certifications. Follow HillTech for more straight talk on Agile, AI, and building things that matter.
What’s your take — are retrospectives essential or overrated? Drop a comment below or connect with us on Instagram @hilltech_tech.