It is time for the retrospective. The team comes in the meeting and looks at the agenda. You can see them checking their phones and being bored. The team feels that the retrospective is a waste of time. They do it because they have to, because 'you know...it is scrum. So you are supposed to do one.'. But it has never led to any improvement. The team has to think hard to even think of one thing they can improve. They are happy to have done the review and are happy that the customer is happy. What more could you want?!
In the video below you find a short example of a really bad retrospective. If you ever see anything like this you need to take time to fix the underlying causes before you proceed with other retrospectives.
Underlying causes for poor retrospectives
A retrospective can be a very fun and inspiring meeting, but it can also be a total energy drain. There can be several reasons for this energy drain:
- The team is very much oriented towards delivering value for the customer and sees all else as a luxury. Imagine a team full of specialists (See my blog on the Belbin team roles) in a retrospective.
- The team is not really a team yet, so people do not feel safe discussion anything other than the product.
- The team does not feel empowered to change processes, tools, facilities or collaboration.
- The team feels that following up on the actions from the retrospective is not actual work, so they consistently prioritize the actions after the actual work of building the product. This leads to each retrospective feeling like a groundhog day without any tangible results.
- Each retrospective has exactly the same approach, leading people to go on autopilot and forget to really think things through.
When you consistently have poor retrospectives you need to use the retrospective to analyze the underlying cause and fix it with the team. Usually you need to help in teambuilding of empowering the team (again) to make their own decisions with regards to processes, tools and collaboration. If you do not do this in time you will see people giving up on the retrospective because it is not right for them. Once you fixed the underlying causes you can start to work towards truly inspiring retrospectives. First some basics:
What is the purpose of a retrospective?
Each sprint ends with the retrospective. The purpose of the retrospective is to learn from this sprint so you can be even better in the next sprint. You talk about processes, moments you felt good or bad, collaboration, tools, facilities, relationships and lot more. There is one thing you do not talk about: The product. You discuss the product in the sprint review. The retrospective is about the team.
Who is involved in the retrospective?
- The scrum master facilitates the retrospective. The scrum master helps the team prepare and follow up on the retrospective.
- The development team participates in the retrospective. They make sure they show up with some ideas about what they feel went well and what should be improved.
- The product owner also participates. They participate as part of the team.
Depending on the context of the project it may be a good idea to involve other roles as well, as long as those people know that they are there to help the team improve and that they need to take the feedback from the team seriously.
What does a typical retrospective look like?
Try not to fall into the trap of just ticking of the boxes of this agenda and use it each and every time. Try to vary the agenda, without varying the purpose or the agenda items.
How to keep the retrospective fun and inspiring
You can use energizers to get people checked in before you start with the substance of the retrospective. Make sure you use an energizer that suits the needs and energy of the team.
For the gathering of data there are just as many tools available as when you look for energizers. Below are two examples I like a lot, one has a more narrative approach and the other is more in the typical feedback points.
There are many ways to prioritize actions from the retrospective. As long as you do not let them fall of you priority list when you start to compile your sprint backlog. You can find some of the ways to prioritize the work in this blog on prioritization (link).
