I’ve heard many times that the retrospective is one of the useless meetings in the sprint. Many teams are not doing it at all. Very often they are not performed properly and they give no outcome. I will tell you why it is crucial to have a retro once a sprint and how to do it properly and milk it for all it's worth.
When should it be performed?
Retro should be performed by the whole scrum team once a sprint - after the Review. This is the spot between the end of one sprint and the beginning of the next one. It is a great spot to summarize all the good and bad things in the finished sprint and leave enough space to include potential improvements in the upcoming sprint. Retro done in the following sprint might cause confusion, because we are talking about the previous sprint and some topics can be mixed up or just be forgotten. Just do it somewhere after the sprint review - do not leave it for later.
What is the purpose?
A retro is an opportunity to summarize the sprint and discuss some pain points in the team, to appreciate a team member, or just to raise an idea. I think that there is one more thing that is not measurable and not taken into account in listing retro outputs - it is building up team chemistry and will for improvements.
Building up a strong team on retro.
But how can you build up a team in a meeting for a sprint summary? Twofold, firstly it lets people express their thoughts and feelings and open towards themselves. It is not going to happen on the first retro, but after some time if the team is participating actively, it allows them to say more without hard feelings. In Codetain we reached a level when people can say basically everything, they can argue during retro and still be good friends after that. This allows us to be 100 % transparent and leads to the possibility of changing things that are not even raised on other teams.
The second one is building up confidence and ownership. What we do in Codetain is the retro hosting shift, where everyone will host a retro at some point and it is completely up to a hosting person which type of retro will be used. This makes people responsible for one of the retros, which is creating a will to make it as good as possible.
A good pattern is a half of success
There are many patterns available on the internet. The case here is to not choose one default one and do it until everyone will get sick of it. Diversity in the retro patterns is crucial to not get bored and tendentiously. In Codetain we can make changes with the hosting shift trigger and everyone can use his favorite pattern. Even if they seem similar, the small differences might make a difference in the phrase of the card.
Some examples:
Good/Bad/Improve - In my opinion, this one is the most common and boring. Something is either good or bad. Ideas for improvement are also typed in the front, not emerging from the discussion.
Sad / Glad / Mad - Also pretty straightforward, but a bit different than the previous one. We have differentiated sad and mad as „negatives” and glad as „positives”.
4L: Learned/Loved/Lacked of/Longed for - A bit more complex one. It allows us to share what we learned during the sprint, what we loved in it, what we lacked and longed for. I think the description of the titles is self-explanatory. A very interesting one - usually triggering a lot of interesting thoughts.
Seriously Uncool/Uncool/Cool/Sub Zero - This one is „borrowed” from the popular car show (Top Gear) rating table. Very straightforward with a gradation of the „positive” and „negative” areas. It can also give some thoughts on how important are some topics for certain people in the team.
These are just 4 examples, but there are many more patterns, even some crazy visualizations like e.g ship: https://miro.com/guides/retrospectives/how-to-run-sailboat-retrospective.
I encourage you to experiment a bit with different patterns - they give much more fun and diversity in the retros.
Executing the outcome
The last part of the retro is ensuring that it will bring a useful outcome. Discussions about problems are not resolving anything, we need some trigger. And there comes action items. In Codetain we are defining action items in agreement with others. If the common ground is defined, we just need to make sure it will be executed. How often did you see set action items but no one cared to tackle them? It is because of the split responsibility - if it is set for everyone - then it is set for no one. That's why we are looking for the coordinator or person who will handle the task and attach his name to the card. This approach significantly increases the chances of executing action items.
Continuous improvement
Retrospectives are happening every sprint, which makes us a constant source of the action items for improvement. We learned through many retros that if they are run honestly and consistently - they bring continuous improvements for the team. Even if the outcome is marginal, all small steps are piling up and making a huge difference in the longer perspective.