Retrospective of Retrospectives

Posted by Deborah Hartmann Preuss on Sep 17, 2009

Sections

Process & Practices,

Enterprise Architecture

Topics

Agile ,

Leadership ,

Governance

Tags

Management ,

Retrospectives ,

Complementary Practices

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.

1. Back to top

   Sort of off-topic (applying the RoR concept across a Whole Company?)...

   by Stephen Starkey

   Has anyone experimented with using the Retrospective approach (and this Retrospective of Retrospectives is very relevant to what I'm talking about) in a larger context? The author talks about keeping the Tech Systems agile, but what about the rest of a company that isn't necessarily wholly technologically focused?
   
   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.

   Reply

2. Back to top

   Another spin on RoR

   by Tim Elton

   The team retrospectives should be a safe zone to "put it all on the table" so to speak. That means that the team members' boss(es) should not be present in the retrospective. Like it or not, most people behave differently around the boss, even if the boss is awesome.
   
   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.

   Reply

3. Back to top

   retrospective facilitator

   by frank olsen

   we use on person (a scrum master on one of the teams) to facilitate all retrospectives. He then acts as the 'knowledge bridge' and should be able to see any issues across the teams and can act upon them. Effective, non-bureaucratic, less meetings. This is kind of like described by Henrik Kniberg: www.infoq.com/minibooks/scrum-xp-from-the-trenches

   Reply

4. Back to top

   Re: Sort of off-topic (applying the RoR concept across a Whole Company?)...

   by Deborah Hartmann

   Hi Stephen.
   
   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

   Reply

5. Back to top

   Re: Sort of off-topic (applying the RoR concept across a Whole Company?)...

   by Deborah Hartmann

   PS: I think a good followup to such a retrospective could be an Open Space event, where people can follow up on the passionate topics that come out. I've not had the opp to try it, but hope to soon!

   Reply

6. Back to top

   Re: Another spin on RoR

   by Deborah Hartmann

   I share your concerns about respecting team integrity and the effect of bosses' involvement. This should be thought through carefully, realistically, in the context of the given organization's culture. Don't be optimistic here - be realistic. Retrospectives are provocative and can bring out people's reflex responses, not just their best selves.

   Reply

7. Back to top

   Re: Another spin on RoR

   by Diana Larsen

   A simple way to allay the fears of team about managers hearing "dirty laundry" is to put the control back in the hands of the team. As part of Closing the Retrospective, ask the team which bits they want communicated into the RofR (and possibly, on which ones they'd like to apply "Vegas rules"). The team member who participates in the RofR has the responsibility to disclose only what has been team-approved.
   
   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.

   Reply

• Older >