Retrospective: Six Voices Out of Nine
You are facilitating the Sprint Retrospective for a nine-person Scrum Team: four developers, two QA engineers, the Product Owner, a contract developer who joined three weeks ago, and yourself as Scrum Master. This is a 10-working-day Sprint and the retro is timeboxed to 60 minutes. By minute 22, during the "gather data" activity, a pattern is visible: the two most senior developers have taken 14 of the last 18 speaking turns, both QA engineers have not spoken since the check-in, and the contractor has said nothing at all. When you ask the room what stands out, one senior developer says, "Honestly, we already know what the problem is - can we just skip to the actions?" Two other people nod. The team's working agreement, posted in the shared doc, says "everyone contributes," but nobody has referred to it.
1. At minute 22, what exactly do you say and do? Explain why you chose that intervention over the alternatives you considered.
Read the worked answer
Name the process, not the people. Something like: "I want to check how we're working, not what anyone said. In the last 18 turns, two people took 14. That's a signal for me, not a criticism - the people closest to the work often have the most to say. But there are nine of us and I'd rather hear more of the room before we jump to actions."
Why this and not the alternatives: telling the two seniors they are dominating invites defensiveness and makes them the topic; asking "can we hear from the quiet ones?" labels people and puts them on the spot, which usually produces silence. Airtime data is legitimate facilitator content - it is an observation about the process, which you own, rather than about a person, which you don't.
Crucially, follow the observation immediately with a change of format, not just a request. Ask for three minutes of silent writing (“the one thing that most affected this Sprint”), then read or cluster, then a round where each person gets 60 seconds and may pass. If you only ask people to speak up without changing the medium, the same pattern reasserts itself within five minutes. You are redistributing airtime, not silencing the seniors - their input is still valuable.
2. The senior developer wants to skip to actions. How do you respond, and how do you spend the remaining 38 minutes?
Read the worked answer
Treat the request as information, not obstruction. It may mean the team genuinely shares a diagnosis, or it may mean the data phase is uncomfortable. Test which: a quick poll (“fist of five - how confident are you that we all see the same problem the same way?”). If confidence is high, you can compress; but you still need the silent voices, because the reason they are silent may be precisely that the diagnosis is not shared.
Remaining 38 minutes: 5 minutes silent writing on the single biggest drag this Sprint; 10 minutes in mixed triads (deliberately pairing a senior with a QA engineer and the contractor) to build themes; 10 minutes clustering and a dot vote to pick one or two themes; 13 minutes on experiments, each with an owner and a check-by date inside the Sprint.
Two disciplines: protect the action phase, because a retro that produces a long list and no experiment has failed; and record the request to skip, plus who nodded, as an observation for next time. If a chunk of the team believes retrospection is theatre, that belief is itself the most important thing in the room.
3. When you invite one of the QA engineers, they say: "I don't have anything to add, the devs know more than me." What do you do?
Read the worked answer
Don't argue and don't move on. This is usually about safety and format rather than content, so lower the cost of contributing rather than pressing harder.
Three options, in order. First, change the channel: "jot one thing on a card, I'll read them all out without names." Written and anonymised input removes the performance element. Second, ask a question their role uniquely answers: "you see the build failures first - what did you notice in the last two weeks that the rest of us wouldn't have?" Specific, role-anchored questions work far better than "any thoughts?". Third, if they still pass, accept it and follow up one-to-one afterwards. Forcing participation in front of peers damages the safety you are trying to build and is a poor trade for one comment.
Do not make the person the topic of the room. But do capture the statement itself as a retro item for a future session: a team where QA believes “the devs know more” has a structural problem - probably about when testing is involved and whose judgement is trusted - that will outlast this meeting.