Retrospectives are awesome and should be fun – game your way through! I use a combination of a few strategies (games) to make my (our) retrospectives work. Developers tend to be closed personalities and are mostly not interested or aimed at processes (and the improvement of those). The problem is that they are your main input for what the retrospective stands for: improving your scrum processes.
No matter how good a Scrum team is, there is always opportunity to improve. Although a good Scrum team will be constantly looking for improvement opportunities, the team should set aside a brief, dedicated period at the end of each sprint to deliberately reflect on how they are doing and to find ways to improve. This occurs during the sprint retrospective.
The games that I’ve learned to use during my career that seemed most valuable and usable (there are a million ways and games out there, gather and use them – by trial and error).
The main goal is to set an environment for your team in which they feel safe, trusted and open to share. An environment where the individuals that make the team feel that their feelings are respected and most definitely an environment in which the team can deal with the issues at hand. Those issues can be process-wise, personal or perhaps even Product Owner, Scrum Master or Stake-Holder related. Any issue with Scrum in general should be spoken of, because they are (potential) roadblocks in an effective and good Scrum.
One-score
To start the meeting easy and gentle I ask all team members to individually score their feeling for this sprint. They write their score (1-10) down on a sticky note. Gather those and put them up on the whiteboard (in order). Don’t analyse the scores yet – just briefly notice if the scores defer much, or if they are rather close to each other. Make sure that your team understands that it’s important to be honest.
What I tend to do (to make the results of this first exercise clearer) is split the whiteboard up into 4 columns (we’ll reuse those later). The column values are (in my case):
- Super (9-10)
- Good (7-8)
- Alright (5-6)
- Negative (1-4)
Doing the above (stick the notes in the appropriate column) gives you a very clear ‘mapping’ of feelings. It helps your team members to get their thoughts and feelings in one line (before we start the other games).
One-word retrospective
This one boils down to practically the same as the above. Ask your team members to write down how they feel about the last iteration (sprint) in one word. Gather the sticky notes and stick them in the appropriate columns. By now they should be filled up with two sticky notes per team member, one with a number and one with a word.
Some people set “real feelings” as boundary; the word written down has to be a real feeling (like, love, hate, cry, fear, etc). I try to leave it free. There’s a game called ‘Car Brands’ where a team literally writes down the car brand that best fits their feeling for a certain sprint (I love that one).
I usually try to leave it up to the team (leaves more wiggle and negotiation room in the next games); they can write down any word (as long as they will be able to explain it later).
As an alternative to this game you could have your team draw something (get them out of their chairs and make them draw something on the back of the board (just get the blood flowing a bit and make your team actively take part of the meeting)
Asking Questions
A quick and relatively easy way to get a bit deeper into the problems (after the other exercises) is ask the team “the four key questions” (Norman Kerth). Those questions are as follows:
- What did we do well, that if we don’t discuss we forget? (Super)
- What did we learn? (Good)
- What should we do differently next time? (Alright)
- What still puzzles us? (Negative)
The goal with those four simple questions is to urge the team to look for things they would like to change.
This game is open, the Scrum Master writes down the responses of the team to each question (try to get as many answers as possible per question). Write them down and stick them in the appropriate lane answers to question 1 go into the ’Super’ lane, answers to question 2 go into the ‘good’ lane, answers to question 3 go into the ‘alright’ lane and answers to question 4 go into the ’negative’ lane (see any correlation there? ;o)
Evaluation
This is the part where we get to the actual core, the FUN part, the part where we (as a team) decide what is going to change and how!
1 – Start by going over the scores that the team have given the previous sprint. Don’t go deep yet, just see if they match with the outcomes of the other two games – no need for more depth yet, we’ll get to that in a bit. I like to check two things:
- Check if the scores that were given are close to each other, if they are.. well done! ;o You have a team that is well aligned and thinks the same! (be sure to celebrate that as a team!)
- If the scores are further from each other: something’s off in your team, ask why they think the scores are so far apart (perhaps there was a personal matter, or someone is just not feeling the vibe for a week, but it could well be that there’s something deeper going on!)
- Check if the scores align with the outcomes of the other games (having all scores in the ’Super’ lane, but having most of the other sticky notes in the other lanes means there’s something weird. Ask yourself and the team what might be the cause of that (don’t go in depth) and (write down any outcomes, they’ll be helpful in the next steps).
2 – I like to do the above for the second game (one-word-retrospective) as well, it generally creates the same output – write it down, use it in the next step and in your report!
3 – Now comes the most important step. Ask questions about the answers (see those sticky notes) that were given to your four questions! There’s no set way, but I try to start on the ’Negative’ lane and work towards the ’Super’ lane, that way we can end with the super positive (awesome) stuff!
Go as deep as you can get (as deep as you feel comfortable with). It’s hard for any person to write down the real problem, what you get (what you see in the board) are the first-level problems. The underlying problem is much harder to get to, much harder. Ask questions to get deeper into the matter. Understand what the problem is, but more so what the cause for the problem is. Try to find solutions for each problem in an open discussion with your team. Let them make suggestions on how to improve the process (or people) to prevent us from having this problem the next time.
Be sure to write down what was discussed, that goes for the first two steps but most definitely for the last step. I like to make a picture of the final board (it helps me in writing my retrospective report, and i actually include it in my report – it looks nice!). I like to take older reports, to see if problems or issues have been there the same way in the last sprints, if we have improved them over the course of the last sprints or if we’ve completely solved them. It gives you a clear view on progress made, and it can show you if issues popped up because of solutions for earlier issues.
The above is my way of doing retrospectives, as stated before: there is no set way to be doing this. It all depends on your team, your organisation and the context.