The first time Priya noticed something was wrong, nobody was arguing anymore. That should have felt like progress.
Six months earlier, the team used to debate everything: API designs, sprint commitments, deployment risks, technical debt. Retrospectives were loud—messy sometimes, emotional sometimes—but alive.
Now meetings ended in thirty minutes. Everyone agreed quickly. Too quickly.
🤐 The Silent Meeting
Late November in Munich meant it was dark outside before the workday ended. Priya joined the sprint retrospective five minutes early and watched people enter Zoom one by one. Lukas joined without a camera, Nina called in from her kitchen, and Martin, the engineering manager looked distracted, typing on another screen.
| Went well, Didn’t go well, Action items: The company had been using the same template for almost two years. |
At 4:02 PM, Priya smiled professionally and started. “Alright everyone… how did the sprint feel?” Silence. Not hostile. Not uncomfortable. Worse. Tired silence.
Eventually someone typed:
“Deployment process still slow.”
Another: “Too many requirement changes.”
Then: “Testing compressed again.”
Priya stared at the board. She had seen these exact comments before. Not similar ones. The same ones. Almost word for word.
A year earlier, she would have challenged the team. “Okay, but what’s the root cause?” Now she just nodded and continued facilitating. Because somewhere along the way, she had stopped believing the answers mattered. And maybe the team had too.
📊 The Dashboard Illusion
The strange thing was that leadership believed the team was healthy. Velocity was stable. Ceremonies were happening. PI objectives were green.
During town halls, executives proudly used phrases like:
- “continuous improvement”
- “high-performing agile organization”
- “strong engineering culture”
But Priya had started noticing smaller things. Things dashboards never show. People no longer laughed before retrospectives. Junior developers stopped volunteering ideas. When incidents happened, everyone spoke carefully, like politicians during interviews. And the strongest engineers had become emotionally quiet. That last part frightened her most.
💭 Daniel’s Silence
Daniel used to be impossible to stop once architecture discussions began. He challenged everything—sometimes annoyingly—but he cared deeply. Now during retrospectives, he mostly leaned back silently with folded arms.
When Priya directly asked for his thoughts, he would shrug gently and say, “I think we already discussed this last sprint.” The first few times, she pushed harder. “Yeah, but maybe there’s a new angle?” Eventually she stopped asking.
Because the truth was painful: there usually wasn’t a new angle. The problems were real. Everyone knew the problems. Nothing changed anyway.
🚨 The Incident
Three weeks later came the release incident. Friday evening deployment. Critical payment failures. Customer escalation. Executives suddenly attending engineering calls.
By Monday morning, the atmosphere inside the company had changed completely. You could feel it even through Slack messages. Shorter sentences. Delayed replies. Everyone trying not to become the person blamed.
🎯 The Blame Game
The retrospective that week started differently. Nobody came early. No small talk. Priya opened the board and forced optimism into her voice. “Okay… difficult sprint. Let’s talk openly.”
For a few minutes, nobody spoke. Then Martin broke the silence. “I think QA validation should have caught this earlier.” The sentence landed heavily. Nina looked down immediately. She was the QA lead.
Priya waited for someone to redirect the conversation toward process or systemic pressure. Nobody did. Martin continued talking about missed edge cases. Developers started explaining incomplete tickets.
📚 The Pattern Has a Name
What Priya was witnessing wasn’t unique to her team. In Retrospectives Antipatterns, Aino Vonge Corry identifies 24 distinct reasons retrospectives fail, and Priya’s team was experiencing several simultaneously: the “Prime Directive Ignorance” pattern (where blame replaces learning), the “In the Soup” pattern (discussing problems no one can solve), and perhaps most dangerously, the “Disregard” pattern—where teams go through retrospective motions without believing change is possible.
Diana Larsen, co-author of Agile Retrospectives: Making Good Teams Great, observed that the most insidious retrospective failure isn’t loud conflict—it’s the quiet resignation when teams stop believing their voices matter. The ceremony continues, but the learning stops.
📉 When Dashboards Lie
Leadership’s confidence in green metrics while the team silently deteriorated mirrors a pattern Tom DeMarco and Tim Lister warned about in Peopleware: Productive Projects and Teams. They wrote: “The major problems of our work are not so much technological as sociological in nature.” Velocity charts and PI objectives measure output, not the psychological safety required to sustain it.
| Google’s Project Aristotle analyzed 180 teams and found psychological safety was the strongest predictor of team performance, explaining 43% of performance variance. It mattered more than individual talent, structure, or clarity of goals. |
Yet most organizations still measure what’s easy to count rather than what actually matters. They track story points completed while missing the moment their strongest engineers stop speaking up.
🏢 The Real-World Casualties
The pattern Priya’s team was following has destroyed organizations far larger than a single engineering team. Consider these cautionary tales:
| Company | What Happened | The Silence That Enabled It |
| Volkswagen Dieselgate | Systematic emissions fraud affecting 11 million vehicles | Fear culture and low psychological safety prevented engineers from challenging unethical decisions |
| Boeing 737 MAX | Two fatal crashes, 346 deaths, 20-month grounding | Engineers felt pressured to rush, safety concerns were dismissed, speaking up became career-limiting |
| Barings Bank | $1.4 billion loss, 233-year-old bank collapsed | Cultural clashes and weak controls meant warning signs were ignored until catastrophic failure |
| GM Ignition Switch | 124 deaths, 10-year cover-up | Distorted company culture where bad news didn’t travel upward, problems were buried rather than solved |
In each case, the technical problems were solvable. The cultural problems were not. Teams knew something was wrong. They stopped saying it out loud.
🎵 The Spotify Model Illusion
Priya’s company, like many others, had adopted “squads” and “tribes” inspired by Spotify’s famous model. What they didn’t know: Spotify never fully used the model as documented. It was aspirational, already outdated when published, and worked only because Spotify had deep engineering trust and tolerance for failure built into their culture first.
Companies copied the structure without the cultural foundation. They got the org chart without the psychological safety. The result, as Kent Beck observed in Extreme Programming Explained, is “process without values” ceremonies that look like agile but feel like theater.
| Warning: Adopting agile structures (standups, retrospectives, sprints) without building psychological safety first creates what researchers call “zombie agile” teams going through motions while the actual learning and adaptation dies. |
💡 What Priya Didn’t Know Yet
Sitting in that blame-filled retrospective, watching Nina shrink under Martin’s criticism, Priya didn’t yet understand the full scope of what was happening. But the research was clear:
- The cascade effect — Amy Edmondson’s research shows that when psychological safety drops, team learning stops first, then innovation, then basic problem-solving. Priya’s team was in stage three.
- The silence spiral — Once the strongest voices go quiet (like Daniel), others follow rapidly. Junior engineers learn that speaking up is career-limiting.
- The measurement trap — What gets measured gets managed, but psychological safety is hard to quantify. So it gets ignored until the damage is catastrophic.
- The incident paradox — Major failures temporarily increase honesty, but without systemic change, they accelerate blame culture instead of learning culture.
The incident that brought executives to engineering calls wouldn’t fix anything. It would make everything worse. Because the team had lost the one thing they needed most to recover: the belief that speaking honestly was safe.
❓ The Question Nobody Asked
In Adrenaline Junkies and Template Zombies, Tom DeMarco’s team describes the “Template Zombie” anti-pattern: organizations that follow processes religiously while ignoring whether they’re actually working. Priya’s company had perfect retrospective attendance, consistent formats, and documented action items. They had everything except the one thing that mattered.
Nobody was asking: “Do people feel safe enough to tell the truth here?”
Not in retrospectives. Not in one-on-ones. Not in anonymous surveys. The question itself had become unsafe to ask.
And so the retrospectives continued. Every two weeks. Same template. Same problems. Same silence. Until the next incident. And the one after that. Each one proving what the team already knew but couldn’t say: The process was working perfectly. The culture was dying.
References
Retrospectives Antipatterns – Aino Vonge Corry
Agile Retrospectives: Making Good Teams Great – Esther Derby & Diana Larsen
Extreme Programming Explained – Kent BeckThe Five Dysfunctions of a Team – Patrick LencioniPeopleware – Tom DeMarco & Timothy Lister
Spotify Engineering Culture Part 1Scaling Agile @ SpotifySpotify Doesn’t Use the Spotify Model
Fear and respect: VW’s culture under Winterkorn
Google Project Aristotle – re:Work
Leave a Reply