Separate Retrospectives

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.

Post to Twitter Post to Plurk Post to Yahoo Buzz Post to Delicious Post to Digg Post to Facebook Post to MySpace Post to Ping.fm Post to Reddit Post to StumbleUpon

Comments (7) to “Separate Retrospectives”

  1. Thanks for this post.

    I reached a simillar conclusion for a project I coach. People were only raising “acceptable” issue. I was forced to advise them to do a retrospective without “business people”.
    We tried that last week, and non-popular issues have been raised and tackled.
    I think this was the right decision.
    The point is to align the composition of the ritual with the organisation (it guys vs non-it guys).
    I find it sad, non agile (re-read the manifesto), but it was the only way to be efficient.
    Perhaps is it a first step. When the (IT part of) the team will be confident, we may try to bring the rest of the team.

  2. I think it’s too easy for teams to start to have ineffectual retrospectives, they’re just going thru the motions and not really making their commitment to improving mean something. After 8+ years, my team has to make an effort to keep our retros valuable

    Even if the team retros go well, I’ve found value in having different “communities of practice” get together. In a large company, this might be everyone interested in testing getting together to watch a demo of how one team is solving a particular testing problem.

    Recently on my team, we testers decided to get together and talk about testing and ideas we wanted to try. Some good ideas came out which we brought to the whole team and we are experimenting with those now. It’s been really beneficial. It isn’t that we are afraid to speak up in retros, but there are so many potential issues to discuss, we might not focus on testing.

  3. I’ve found it useful to have a very technical retro of use to the devs and a nontechnical one for all to participate in.

    George, will you tell us which safety exercise you used in this case and why you chose it? Perhaps it be good as another post. Thx

  4. Great post.

    I am interested to know what the “norm” is for participation in retrospectives. From reading your post I think the retros that I run are technical ones as I only do it with the development team. I was advised by a coach that having the business or even the product owner involved wasn’t ideal.

    I could see a release retro being the place for all hands being involved though.

    What are peoples thoughts on this?

  5. Justin, who do you consider to be part of the team?

  6. […] Effective software development « Separate Retrospectives […]

  7. I am glad you explored this topic because it is a great technique that should be considered if you are added as a coach to a dysfunctional team. However, I always exhaust multiple retrospective techniques before I conduct separate sessions with different groups. This typically works wonders. When it fails to, I find it difficult to assess what technique will work best for troubled teams. As such, I cycle through several retrospective approaches to ensure no one is withholding their true feelings. If the desired body language and positive vibes still fail to surface, it is time to really dig in and separate groups or even individuals until everything is on the table. Then, it is important to choose a technique that visualizes issues so the team can reassemble and really dwell on things before responding. This is an important safety measure as it allows team members to work through any negative emotions they feel before solving the issue. Otherwise, immediate verbal discussions can quickly digress in to something less than amicable. Obviously, you begin to enter a realm beyond that of the typical retrospective, but the payoff is huge if things pan out. Even if they fail to because of such efforts, you have a clear indication that the current team needs to disband, as they will fail to produce needed results.

Post a Comment
*Required
*Required (Never published)