Why Do Teams Find It Difficult to Do Agile Retrospectives?
Retrospectives are often considered to be a valuable agile technique, as they support teams to reflect and adapt their way of working and help them to improve and deliver more value to their customers. But sometimes teams find it difficult to do retrospectives. Team members can feel that they don’t control things that need to be changed, think that they can’t improve any further, have difficulties defining good actions, or start complaining in stead of defining actions. They may find that retrospectives are boring, and feel that they are a waste of time. How can you deal with these difficulties, and help teams to discover better ways to do retrospectives?
The blog post agile concept of the week: retrospective by Keith McMillan gives an overview of what retrospectives are, how to do them, and what you can do when teams have difficulties doing them. He starts by explaining why to do retrospectives:
The principles behind the manifesto include “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts it’s behavior accordingly”. The most common way this is done is the retrospective.
Keith mentions some difficulties that he sees teams having when they are doing retrospectives:
- (…) teams [are] unwilling to challenge what they perceive as organizational requirements outside of their control
- (…) the team feels they’ve optimized their behavior, and doesn’t think they need to change any more
- Some teams have difficulty coming up with something they’d like to try
- Some teams retrospectives unfortunately devolve into complaining about what other teams should do, or complaining about things that are one-time occurrences
His blog provides a solution for each of these problems: Executive sponsorship, competition between teams, additional action categories and carefully steering teams.
In retrospectives, part 2: In a sentimental mood, Olga Kouzina explains why teams can have difficulties when they start doing retrospectives. She states that “a team has to be mature enough to hold retrospectives”:
One of the common pitfalls is when teams are eager to run retrospectives just for the sake of running retrospectives. They know that if they are supposed to be agile, they need to do retrospectives. But it’s not as simple as following a guideline. The need has to come from within. The team has to develop this intrinsic feeling of power to solve their problems and – even more important – to accept the responsibility.
Olga gives some things that you can look at to see if your team is mature enough:
- no-blame culture
- [no] finger-pointing
She did a root cause analysis to find the deeper reasons why people do not want to attend retrospectives:
Most typically, the chain of whys will uncover one and the same issue: a retrospective is not a meaningful activity. Sometimes, a retrospective is just a ritual the team leader or the CEO is following to do agile by the book, while in reality they’re well aware of all the problems, and already have some solution in mind. So, a retrospective in this case is more of an opinion-check meeting to sense the atmosphere in the team, and to see if the leader’s decision is aligned with the expectations of the team or not.
She concludes her blog with some advice to improve retrospectives:
Quite often, in a larger organization, there’s no real lever to influence culture shifts for people assigned to run retrospectives. If someone is confined in a certain space, like, a singled out task of doing a retrospective – then they would look for the ways to create some ado around this ritual, and operate in the limits for which they’re accountable. Role play, shuffling moderators, allocating fixed times, inviting clowns etc. — such advice is tailored to this very audience.
In the blog post how to improve your sprint retrospective meeting?, Rini van Solingen describes the difficulties teams can have with retrospectives:
Although retrospectives are very important to make Scrum work, many teams struggle with them to keep them actionable, energized and focused. Some even stop doing retrospectives because they fail in keeping them effective. This really undermines Scrum; without retrospectives the continuous improvement cycles is cut out. Running effective and enjoyable retrospectives is not easy.
The common mistakes he sees with retrospectives are:
- Retrospectives become a dull and boring routine
- Too many non-actionable improvements
- Focus on what can NOT be changed next sprint
Rini gives 5 tips to improve retrospectives: Vary with formats, kaizen, define a goal, involve management, and no tables
Craig Strong starts his blog post top gear agile retrospective describing why he thinks that organization have difficulty to adopt agile retrospectives:
(...) when there are delivery pressures or fires to fight, the retrospectives can feel administrative and are often overlooked, which is a real problem as they are invaluable to continuous improvement.
He wanted a interactive retrospective which the team would enjoy to do and that would get to the root causes of problems and help the team to improve together, and decided to use a retrospective technique called “cool wall”, and themed it using Top Gear. Team members gave him pictures of themselves with cars, and the room was setup with pictures from Top Gear. He read out the retrospective prime directive and asked check-in questions to set the scene for the retrospective. Then he asked the team members to vote on their skills, using the columns “Uncool”, “Cool”, “Super Cool”, or “Sub-Zero”. Using the root cause analysis with the 5 why’s technique the team got insight into the causes of the problems, and using the circle and soup game from Diana Larsen they found actions that were within the team’s control.
At the end of this retrospective he asked the team for feedback, to get insight what worked and what didn’t. His conclusion is:
Overall I found this session to be rewarding and valuable to the team. It was fun, the energy level was high and most of all we identified ways to improve as a team with tangible actions to work with.
Which difficulties do you experience when doing retrospectives? How do you deal with them?