Retros Should Be Awkward Sometimes
An objective of the Sprint Retrospective, according to the Scrum Guide, is to:
Inspect how the last Sprint went with regards to people, relationships, process, and tools
This should sometimes lead to uncomfortable discussions and tough decisions. Retrospectives should sometimes result in change that impacts people, relationships, process, and tool in significant ways.
So why are Retrospectives often timid affairs with discussions of Backlog Items that were not quite ready to work on or issues deploying a Feature?
Let’s take some examples of conversations that should sometimes be happening:
No more full-time Scrum Master
Raised at Retro: ‘We don’t think we need a full-time Scrum Master anymore. We can share the role between us, we have been together as a team for a long time and have good relationships with the rest of the business.‘
Why would this not come up? Talking about roles means discussing a subject that impacts our colleagues and friends. Such transparency and frankness is not yet part of the culture of many teams and organisations.
Feeling let down by team members
Raised at Retro: ‘We don’t think certain teams members (they would not name who) took the Sprint seriously and we feel let down. This has happened three or four times now in recent months. We would like everyone to try and take things more seriously or maybe consider finding other teams.’
Why would this not come up? Discussing individuals’ commitment to a Sprint and to their Team means being direct. And it does not come naturally to a lot of people to be outspoken about their feelings.
Stop doing Retrospectives every Sprint
Raised at Retro: ‘We feel we don’t often get much out of our Retrospectives any more and feel we could use the time more productively. We only want to do a Retro when we all feel we need one.’
Why would this not come up? The Scrum Guide does not permit Scrum to be changed and so this raises an awkward problem, in that, if the retro change is enacted, according to the Scrum Guide, the Team is no longer able to say they are doing Scrum. So often discussions about the Teams’ use of the Scrum framework are dismissed altogether.
We have a lot of ideas for change that never happen
Raised at Retro: ‘We have a long list of improvements items that never get addressed. And we frequently raise the same issues in Retros.’
Why would this not come up? It’s very easy to gather a long list of improvement actions but nothing is worse for moral than great ideas for change languishing in a Backlog. Making change can be hard if it means getting buy from the wider organisation — outside of the Scrum Team. Teams may be reluctant to push for change if it means they will be in the spotlight.
Conclusion
Sometimes you have to be prepared to shake things up and experiment with breaking the rules to figure out what is important.
Retrospectives should be challenging. If your Retros are not encouraging the Team to question all aspects of the way they work and occasionally experiment with significant change then you are missing an opportunity.
The mark of good Retrospectives is that they help both immature and mature teams to find improvements and stay on the rails. Mature teams may be very comfortable and not keen on change. Immature teams may try to make radical changes. It does not matter what the conversion is, as long as it is happening.
It is the responsibility of the entire Scrum Team to find ways get everyone to fully participate in Retrospectives and I think a good indication that Retrospectives are working well is that sometimes they get a little awkward!
