BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Retrospective of Retrospectives

Retrospective of Retrospectives

This item in japanese

Bookmarks

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.

Rate this Article

Adoption
Style

BT