How to have fun and learning at your retrospectives

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 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.

Content not available.
Please allow cookies by clicking Accept on the banner

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. 

The Sprint process

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?

  • Introduction: setting the stage, checking everybody in and define the goal of the meeting
  • Gather and share data: both quantitative and qualitative
  • Generate insights: make sure your insights are based in facts, not opinion. Understand root causes of problems. And most importantly: create shared insights and knowledge.
  • Decide what to do in the next sprint: Decide with the team how you will choose and try not to take on too much. The team needs time to learn and work at the same time. Be sure to check with the team why they want to do something and why they feel it will help them. Most important here: Make sure the team is enthusiastic about the actions. If they are not they will probably not follow through on the action.
  • Close the meeting: Summarize the actions you have agreed on, thank everyone for their contribution and ask how the next retrospective can be even better.
  • After the meeting: Make sure the actions from the retrospective are included in the sprint backlog

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.

A retrospective where you use the narrative of flying to identify opportunities and strength
What to do less, more, what to start, stop or sustain

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).


Add Comment

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.