Retrospective of Retrospectives
Once all your teams use Agile and are implementing local improvements, what happens to the larger organization formerly called "IT" or "Systems Development"? A coach with a large Agile program shared the strategy they designed to let the larger community spot trends and benefit from all this learning. ThoughtWorks' Paulo Caroli calls it "Retrospective of Retrospectives". As always with large programs, there are tradeoffs to be considered.
Feedback is a cornerstone of Agile approaches to software development. It's the important pause teams regularly take to "inspect-and-adapt," to watch for and respond to red flags in their processes and products, and to spot opportunities that might otherwise slip by in the rush of delivery. ThoughtWorks' Paulo Caroli noticed, in his program of a dozen 15-person teams, that while improvements were being made at a team level, the overall program was losing focus on continuous improvement.
At times, the action point from one team’s retrospective was dependent on other teams. At other times, two team retrospective action points were contradictory.
Another challenge the program faced was that program level management had no window into issues and improvements. "The program manager (and other people) would like to attend each team retrospective; but it was just not possible to be at several meeting at the same time."
Caroli's solution draws on the wisdom of Scrum of Scrums: Retrospective of Retrospectives, which they shortened to RoR.
Similarly to how the daily scrum is extended to the Scrum of Scrums ... I came up with the idea of having a Retrospective of Retrospectives for large Agile teams. ...the RoR context is: "What can we do as one team (the whole program team) to improve the overall output for the program?"
The RoR participants include representatives of all team and of the program, including each team's manager and one other team member (this last is recommended, possibly on a rotating basis). His writeup indicates no participation by Product Management, but this may be buried in the role names used. The meeting's starting point is the top 5 items from each team's retrospective. Repetition is eliminated and the results are voted upon (presumably to determine order of discussion).
Here we run into the catch-22 of large programs: yes, it's difficult for the managers to get around to all the teams in person. So, the teams come to the managers. This many-to-many meeting then presumably becomes much larger than the Agile-recommended small group, and facilitation would need to compensate for the loss of intimacy in this meeting, in comparison to a regular retrospective.
Key benefits noted by Caroli include:
- all managers and stake holders have visibility on the top items for each individual team.
- all this is available in only one meeting.
- common goal: all attendees are periodically talking and acting on the overall goal of the program.
- everyone is heard – Any local team problem will be heard by all the teams.
This list raises the question: what happens to retrospective confidentiality, here? With this scheme, expectation setting would have to be done at the team level, knowing that it could potentially influence the dynamics of future team retrospectives. Would team members still be willing to delve into touchy topics, knowing that non-team members (without team context) would hear the results? In a high-trust, high integrity organization the benefits of this scheme might outweigh the risks.
Sort of off-topic (applying the RoR concept across a Whole Company?)...
by
Stephen Starkey
For example: a financial services firm (sort of like what I'm dealing with) struggles with remaining nimble in all aspects of business, some of them technological, others very much not. I've been playing with using Retrospectives to work out overall cultural issues by breaking each division into its own retrospective and then "rolling up" the results of that retrospective that are cultural in nature (as in: intra-unit concerns) into a larger retrospective to be held semi-annually or even quarterly.
The issue I'm having is in selling the idea of a Retrospective to senior management as a Good Idea (I can see parts of even the Agile Retrospectives book that work well in any arena) for overall cultural improvements. After all, any activity you can do with a bunch of programmers/analysts/etc. can probably work with lawyers, accountants, and so on, right? Well, notwithstanding strange personality quirks, power struggles, etc.
I know.. it's radical and possibly (*gasp*) democratic, but I wonder if other folks have this experience? It all assumes a fairly flat organization (which we strive for here), but I'm also considering trying to use it as a vehicle for "democratizing" the company slowly from the grass-roots.
Another spin on RoR
by
Tim Elton
I would think that an effective way to structure the RoR, would be to shuffle all teams' retrospective feedback into one list. To preserve anonymity, the items on the list should be disassociated from team identities. Then, the RoR meeting could be held with management and perhaps representatives from each team to identify trends and plan action items.
retrospective facilitator
by
frank olsen
Re: Sort of off-topic (applying the RoR concept across a Whole Company?)...
by
Deborah Hartmann
I have used Retrospective techniques with management. Here, I found the mix of management and other roles very useful - parties were astonished to discover the very different perceptions held by people in different roles in the organization!
In one instance in particular: top level leaders were shocked and dismayed at how their actions were (mis-?) perceived by software developers. More transparent and clear communication ensued, and doors were opened for developers to offer feedback to upper management.
Yes, retrospectives can be powerful at many levels, from personal introspection to organizational introspection. In an organization, though, be sure to set expectations: these techniques will surface things not currently talked about. Are they willing/ready to deal with these?
And, stick around to help deal with the chaos that ensues, if you can. Out of chaos can come many good things. But people may need help at first, not to fall back into CYA and defensiveness.
deb
Re: Sort of off-topic (applying the RoR concept across a Whole Company?)...
by
Deborah Hartmann
Re: Another spin on RoR
by
Deborah Hartmann
Re: Another spin on RoR
by
Diana Larsen
However, like Deborah, I'd counsel caution about using this approach in a fear-driven organizational culture.
Also, the RofR might be the occasion to bring in a retrospective facilitator who has broad experience managing larger groups with more perspectives. The RofR is more akin to the end of project retrospectives that look across a wider spectrum of what it takes to get the software out the door, and as such, is a more complex meeting to lead.
Educational Content
Concurrency in Clojure
Stuart Halloway May 17, 2013
Confessions of an Agile Addict
Ole Friis Østergaard May 16, 2013
Web Development: You're Doing It Wrong
Stefan Tilkov May 16, 2013
Programming The Feynman Way
Ben Evans May 15, 2013





Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think