But what about large Agile teams? Once again I will use my current large Agile program as a case study:
Lately I have been working on a large Agile program. With the large Agile program, comes common large team challenges, and the need to adapt the Agile development and management practices to better suit the large team challenges.
Currently the program has around 180 people distributed over 12 teams. Typically, each team is formed by 15 people (project manager, business analyst, quality assurance and developers; for short: PM, BAs, QAs and Devs). All teams in the program are following Agile practices, such as 2 week Iterations, Daily Scrums and End of Iteration retrospectives.
The teams were getting good value out of the Retrospective Agile practice. But the improvements were done in a team level. And the overall program was losing focus on continuous improvement. At times, the action point from one team’s retrospective was dependent on other teams. Other times, two team retrospective action points were contradictory.
Another challenge was that the program level management was not able to attend every team retrospective. There were 15 retrospectives happening at the end of each Iteration, 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.
Retrospective of Retrospectives
Similarly to how the daily scrum is extended to the Scrum of Scrums for large Agile teams, I came up with the idea of having a Retrospective of Retrospectives for large Agile teams.
The Retrospective of Retrospectives (RoR for short) meeting is held after each individual team retrospective. The participants (representatives of all team and the program) meet to discuss what went well and what to improve in the program level. The RoR focus is on improving the overall program output, and not on individual team performance.
Data gathering: The top 5 items from each team retrospective is the start point for discussions and possible program action items.
Participants: Similarly to the Scrum of Scrums, all managers participate in this meeting. The attendance of another representative of each team is recommended; and it is encouraged to be in a rotation basis.
Context: The context for the RoR is slightly different than the context for individual team retrospectives. While the context for a end or iteration retrospective might be: what can we do to improve next iteration for our team, The RoR context is: What can we do as one team (the whole program team) to improve the overall output for the program.
Mechanics: Each team retrospective top items are read. Repetitions and alike items are grouped together. Then the items go for voting. (for example 3 votes per participant).
RoR top benefits
Below are the top benefits I noticed from the RoR.
Quick access to all teams – all managers and stake holders have visibility on the top items for each individual team. And all is available in only one meeting.
Focus on improvement – for both the individual teams and the program level. One common problem on large agile projects is that one loses focus on the overall program by constantly focusing on local improvements. It is like being around the trees and lose sight of the forest.
Common goal – All managers (and the selected team members) are periodically talking and acting on the overall goal of the program. The RoR participants carry the common goal message (and action points) back to their teams.
Everyone is heard– Any local team problem will be heard by all the teams. Even if something is specific for a team, the message (team retrospective item) will be heard by all teams.