I was talking recently with a friend about separate retrospectives for sub-groups. They were worried about thing devolving into separate silos, with a retrospective for programmers, a retrospective for testers, a retrospective for analysts, …. I would be worried if that happened, too, but I can see value in separate retrospectives. How can we know when they’re appropriate and when they’re not?
I’ve led a separate retrospective for developers (programmers and testers) at a client making an Agile transition. In that situation, it seemed to me that the full-team retrospective concentrated on “acceptable” improvements—things that were easy to propose in a corporate environment. And I noticed that a number of the developers didn’t say volunteer anything. That was a clue to me that there were things to be said that people didn’t feel comfortable saying. Given the fact that the Scrummaster was a former project manager, this dynamic wasn’t unexpected. Having a separate retrospective, with a safety exercise at the beginning, allowed some issues to be acknowledged, even if they weren’t tackled.
In my friends situation, the majority of the participants are programmers who have, for the most part, worked with each other at other companies. They know each other well and are working together at this company precisely because they get along and respect each other. That’s all well and good, but the side effect is that there’s a bit of a monoculture among these developers. They readily agree with each other within a limited viewpoint.
You would think that a retrospective would bring out other viewpoints and counteract the hegemony of this group. Unfortunately, the group had settled on “majority vote” as their standard means of deciding which topics to pursue in the retrospective. How did they choose that? I don’t know, but I’d guess they voted. Ellen Gottesdiener examines a number of group decision-making approaches in her article “Decide How to Decide.” (Software Development Magazine, January 2001) While majority vote is fast and efficient, it always results in a loser, and sometimes in a persistent loser. For retrospectives, I prefer “Spontaneous Agreement” or “Consensus.” When the group I’m facilitating can’t converge on a choice that hears all voices, I’ll sometimes fall back on “Decision Leader Decides After Discussion” to give those voices a chance.
If you’re stuck in this sort of situation and you’re not the facilitator or otherwise capable of making the decision, then feedback to the retrospective facilitator might be in order. It could be that the facilitator just hasn’t noticed what is happening. It could also be that the facilitator doesn’t yet have the skills to know what to do about the retrospective being consistently owned by a sub-group. Some helpful feedback, stated in terms of observed behavior and personal impact, might be just the thing to break that log-jam. Or, it might not, particularly when there’s a difference in organizational power between the facilitator and the person who wants to help the situation.
Having a separate retrospective of people locked out of the decision-making in the larger retrospective is an escalation of this approach. If one person has been unable to influence the facilitator’s behavior such that all voices are heard, perhaps the group of disadvantaged people can dig deeper into the problem and come up with some more effective solutions. If this group continues to feel the need for a separate retrospective, though, then it indicates a continuing problem.
That’s not a good sign for the organization. Human dynamics of a given group don’t always work out smoothly. And sometimes organizations fail. Being deaf to voices have different information, values, or preferences is a good way to fail. The universe doesn’t depend on every organization succeeding. As an individual, there’s always Martin Fowler’s advice, “Change your organization, or change your organization.“