The shouting match: retrospective anti-patterns

"Well, I think we should definitely prioritise the deployment pipeline issues—"

"No, no, the real problem is that the frontend team keeps changing requirements without consulting us—"

"That's not fair! We only change things when the designs—"

"Can we please focus on what actually matters here? The database performance is killing us and—"

You glance around the room. Three people are trying to speak at once, voices getting louder. The junior developer has stopped taking notes and is staring at their laptop. The tester in the corner hasn't said a word in twenty minutes.

Sound familiar? You're witnessing the third anti-pattern in our retrospective anti-patterns series: the shouting match. We've already covered the group therapy session and the blame game, and today we're tackling what happens when the loudest voices drown out everyone else: the shouting match.

You'll know you're dealing with a shouting match when one or two team members dominate through volume, persistence, or strong opinions, effectively shutting out others.

Your retrospective ends with apparent agreement, but several team members haven't bought in—they've simply been overpowered. Thoughtful and introverted members quietly check out, feeling unheard.

If this resonates, you're not alone. What makes this particularly challenging is that teams solve the wrong problems whilst real issues remain hidden, wasting time and tanking morale.

But when you get input from your entire team, you uncover insights no single perspective could provide. Picture a retrospective where the quiet backend developer shares an insight about technical debt, and a junior developer chimes in to point out a communication pattern senior members missed. Instead of the loudest voice winning, the best ideas rise through genuine collaboration.

That's the kaupapa we're working towards, and here are some ways that you can make it happen:

Structure the session for inclusion

Use techniques that give everyone opportunities to contribute. Try silent brainstorming or "sticky storming"—everyone writes thoughts on sticky notes and adds them to the board without talking. No one can challenge or remove others' ideas, preventing early ideas from anchoring discussion.

Similarly, use "dot voting" to prioritise topics for discussion. Each participant gets fixed votes to allocate to the sticky notes on the board however they want, then discuss from most to least votes. Again, no talking during voting, and no challenging others' choices.

Create a rotating facilitator role

Domineering team members rarely shut out others intentionally—usually a friendly nudge is all it takes to get them to share the spotlight.

Start by taking the facilitator role yourself to model the behaviour. Your job is to notice participation patterns and invite quieter voices. Picture your team’s DevOps engineer talking for five minutes about deployment issues while backend developers sit quietly. You step in: "We haven't heard from the backend folks yet—any thoughts on this deployment issue?" Suddenly you learn about a database connection issue that explains everything.

Or when your opinionated senior developer keeps dominating: "Thanks Mark. Jane, what's your perspective?"

For members uncomfortable sharing publicly, they can send their contributions to the facilitator via a private channel (such as Slack DMs), and the facilitator will present them anonymously to the group.

Once the team gets comfortable with this dynamic, rotate the facilitator role among team members. This prevents any single person from wielding too much influence over discussions and ensures everyone develops the skill of creating inclusive conversations.

Let the retro get (a little bit) meta

If seniority or role differences regularly affect participation, try acknowledging it during the retrospective. Sometimes calling out the dynamic will level the playing field and encourage participants to self-correct.

If the team do want to discuss how to better run retrospectives, just remember: there are no people problems, only process problems—gently redirect from naming names to improving process.

Making it stick

The key is consistency—these techniques only work if used regularly and adapted based on your team's dynamics.

Pay attention to who's speaking and who isn't. Notice which topics generate heated discussion and whether you're getting balanced input. **The goal isn't silencing strong voices, but amplifying quiet ones.**

Your next step

During your team's next retrospective, try this: look around the room (or video call) and identify who typically speaks up and who stays quiet. Then pick just one technique from this post—silent brainstorming, dot voting, rotating facilitator, or naming the group dynamic—and commit to using it consistently for the next three retrospectives. Notice what changes.

We're making good progress through retrospective anti-patterns! I'll be back in a few weeks to talk about Fear of Commitment and how to help teams that struggle to implement process improvements.