Nowadays most agile teams do retrospectives which help them to deal with difficult situations and improve their way of working. But teams don’t work in isolation, they interact with other teams and with their stakeholders to deliver value. Let’s explore how retrospectives beyond the team level can be used to improve collaboration.
Agile retrospectives play an important role when it comes to getting value out of agile. Only when teams and their surrounding organization truly dare to reflect and learn from what is happening, and take action based on that, then improvement is possible.
Retrospectives with multiple teams
Organizations can have projects that divide up in teams, or use a product based development approach where multiple teams work together. There’s a big chance that similar problems pops up in multiple teams; often problems in larger organization have systemic causes which have to do with the way that the organization is managed and the organizational culture. Such problems should not be solved by individual teams, it becomes a lot easier to address and solve them when teams join forces.
If at any time you want to take retrospectives to a higher level with multiple teams, a Retrospective of Retrospectives (RoR) is an effective way to do it. Such a retrospective involves members representing different teams (or all members from every team) to explore common problems and come up with solutions to address them. They can also be used to align teams.
Exercises that you can use in an RoR are for instance “Bubble Up” or “Artifact Contest”. You can also do an RoR with an Open Space.
An RoR stimulates learning across teams and increases collaboration between teams. Organizations can also use RoRs to share experiences between different projects or departments with teams. That’s reason enough to do an RoR at regular times, even if there doesn’t seem to be any major problems.
Retrospectives with Stakeholders
Having the right stakeholders involved in retrospectives helps to get improvement actions done. Stakeholders have the power to make things happen in organizations, they have access to resources and can make decisions with real impact.
My advice is to do retrospectives at major deliveries/releases with all project/product stakeholders next to team retrospectives. It depends on the kind and level of the retrospective which stakeholders need to be involved. For a project level retrospective it could be the project management team which is leading the project, with some members from the teams. For a product retrospective I suggest to invite the product management team, architects, and again team members.
You can also do retrospectives in agile transformation/adoption programs to see how you are progressing and decide how to continue your agile journey. Such a retrospective would be with managers leading the transformation and those involved, agile coaches, and (you guessed it) members from the teams.
The product owner is an important stakeholder for the team. Where people sometimes question if the product owner should attend the team retrospective, I prefer him/her to be there, certainly when there are issues regarding the product backlog, prioritizing, or the quality of user stories.
Don’t forget the team
Let me be very clear on this: Retrospectives with multiple teams or with stakeholders do not replace retrospectives at the team level! It’s essential to keep doing retrospectives in teams!!!
Retrospectives should be done close to the work and by the team itself – that way they will get the benefits from doing them. Many small individual changes create a big team effect, team retrospectives have impact.
When the team becomes better, their customers, stakeholders, other teams, and in the end the whole company benefits. Our book on Getting Value out of Agile Retrospectives contains several chapters with exercises and the business value and benefits of retrospectives. There’s also a blog post on the business value of agile retrospectives.
