More Musings on Retrospectives

PeterJ and I tossed some of this around via e-mail this week, but I thought posting it here might serve as a good exercise, if nothing else. This particular thread was around how to have Retrospectives that were wider in scope than the specific ones that we'd been doing lately: Feature Teams doing Iteration Retro's, and meetings or events that seemed not to go all that well having a Retro to examine what happened and how to make it better next time. All of which are good uses of the Retrospective format. But what about more "overall Retrospectives" as PeterJ coined them?

Which, strangely enough, made my mind go in a slightly different direction (which I'm sure is frustrating for poor PeterJ, but he must be used to it by now): I had been thinking for awhile that even the Feature Team's Retrospectives needed to eventually become more than 'just' reflections on the last Iteration (although those are important, too). So I started envisioning an environment where first each Feature Team does what we've been doing, which is holding fairly inward-gazing Retrospectives, focusing on issues that the team itself has become aware of. At some point, and it's probably a different point for every team, the members decide that they've knocked off the biggest areas of weakness and start to exhibit the ol' cock of the walk attitude about themselves, at which point it's probably time to widen the focus of the next team Retrospective.

For example, maybe that's the time to bring in some customers, and have the next Retrospective examine just how the consumers of the team's efforts perceive the process. In an environment where the customers were more frequently involved, or better yet co-located, with the team, this might not be such a big deal. But we have remote customers, and internal proxies representing them who aren't even co-located with our Feature Teams. So we don't get the volumes of direct feedback Agile calls for. But perhaps the Retrospective framework is just the way to deal with this. My expectation is that, at least in many cases, the Feature Team that's dealt with most of what it can see is wrong with how it operates, may be in for a surprise or two when someone outside the team gets to provide feedback.

Another obvious example of a group to bring into a Retrospective like that would be a neighbouring Feature Team, either in terms of geographical proximity ("What do you mean we're too noisy for you guys to hear yourselves think? Who knew?!") or working relationships ("Yeah, those APIs you provided for us really stunk but we didn't want to say anything because they were better than nothing...").

As a first step in this direction, and with my team's 'blessing' (no one objected, at least), we're going to use our next Retrospective to assess ourselves as an Agile team, rather than reviewing the current Iteration. While still an internal focus, it's at least widening it out a bit beyond what we've done in the past. It should be interesting, at least! :-)