Handy list of retrospective techniques

In the last article, we discussed about agile retrospectives and some important dos and don’ts. Now, it’s time to jump into it further and have a look at some common retrospective techniques that scrum masters use.

You may pick none of these or make your own style by mixing a few of these, because when it comes to a retrospective, it’s about what you want to achieve and how. However, these tried and tested techniques may come in handy for you, so here it goes.

Grading the happiness quotient: You choose your levels such as High-Medium-Low or 1 to 5 and then write them out on a white board. Iterate through the list of discussion items and ask the team members to grade each item by placing a tick mark or a post-it on the white board. Then you choose the items that are graded below an acceptable level, debate why and arrive at solutions to help for future.

When to use: This works when you want to engage in an open discussion. Also, when you’re at the end of the project and looking to understand what went well and what did not.

There are other similar approaches like Mad-Sad-Glad where the team writes what items made them mad, sad and glad. Also, you can useThe Sailboat approach where you draw a boat and write all the positives near the wind, the slowing down factors near the anchor and the future risks near the rocks. These are excellent ways to group good stuff and the not-so-good ones and then have a prioritised discussion.

5 times why: Ben Linder’s book on retrospectives talks about this approach in detail. The method is you ask ‘why’ to a problem statement. After you get an acceptable reply from the group, you ask why again to that reply. You do this iteratively 5 times until you get to the bottom of the problem. This is an excellent Root Cause Analysis (RCA) technique.

When to use: This works more as a problem solving technique, mostly when you’re in the middle of a project and between sprints. So your problem statement could be ‘Why did the testing take more time than usual in the last sprint?’ Then based on what you uncover, you tweak your approach for future sprints. This also works well for getting the team to a consensus because the focus is on the problem rather than people.

One-word game: Ready for a fun rapid-fire round? The facilitator, who is usually the scrum master, reads out a goal, task or a problem statement. Then, he goes around the table quickly and gets each person to say one-word related to it. This potentially explosive game could lead to some interesting follow-up discussions.

When to use: When you need some fun… yes, that too! But, also when you want to squeeze a warm-up session before getting to the core areas of discussion. It sort of shakes up people and sets the tone for the rest of the meeting.

Secret box: As the name says, you have a secret box, where the team can drop in problems and solutions. It makes people open up about problems that they may hesitate to discuss otherwise in a team meeting. The box can also become a list of things to discuss in the next retrospective. So, people can drop in ideas as they remember.

When to use: Typically, when the management feels there is not a conducive environment and sufficient trust for everyone to open up. Personally, I don’t prefer this method because it creates a feeling of secrecy and that should not be the case with a project team. But, if you are really desperate to hear ideas, go for it.

Play to Perfection: This is taking the Mad-Sad-Glad to the next solution level and to force people to think well before grading an item. So, if someone grades an item 7 on 10, he has to come up with reasons for the gap and also present solutions to improve. He also explains the things he liked. The overall approach is of positivity and to take each item towards perfection by fixing whatever gaps are observed.

When to use: It works when you are not there to solve one major problem, but instead to take a bucket list and improvise things. Also, use it when you want to tweak people’s thinking towards solutions instead of just registering complaints.

Starfish: Make a pie chart or draw a starfish and write out (or use post-its) to categorise items as Start, Stop, Do more, Do less and Keep.

When to use: This is a simple approach and can work well for several scenarios – at the end of the project to record ideas, between sprints or even at the beginning of a project when people want to discuss methodologies and approaches. I have also seen individuals use this for their personal development plan.

As you may have observed, there are a wide variety of techniques that help you group your topics/issues/problems/tasks into categories. The idea is that you’ll plan your actions based on that and not just stop with the sorting out.

Fun team exercises: A couple of enjoyable and result-oriented activities are Speed Dating and Choose your Zone.Speed dating is when people go around in a circle and have a one-on-discussion with a specified time-box of say, 10 minutes. This gives an opportunity for pairs to interact and you will find some interesting combinations of people, who may normally not interact. Other than acting as a team building activity, the unique pairs may generate some good ideas, too.

Choose your zone is a ‘yes’ or ‘no’ game. The facilitator reads a statement and people who agree runs to one corner and who don’t agree run to another. It is a fun way to take a poll and also a good precursor to a more detailed retrospective.

Hope this handy list of agile retrospective techniques help in making your sessions more effective. You can also try to make it a little unstructured by going for what the team wants to do. Also, if you have a method you conceptualised and that works very well for you, share with us!