How to choose the right Retrospective format in Agile
Useful for Scrum Masters in agile teams
What is a retrospective in Agile is quite simple by definition: what went well, what needs improvement, and what went bad; and a list with action steps for improvement, with responsibles attached, to be implemented during the following sprint. Process: fill in the post-its, read/discuss them, and generate ideas for action. If there are actions after a retro and many post-its a scrum master may feel fulfilled, right? 😊
It may get out perfectly with a mature, transparent, good communicating team or disastrous with a team that maybe has no reference of how could things be done better because of the lack of experience or knowledge, with communication problems that may have reached some forms of conflict or where management has not agile mindset at all.
A scrum master is in the position to choose what kind of retrospective to use, depending on the maturity-openness-transparence-experience level within the team, also depending on certain events that may happen during the sprint, so a cocktail is needed, the mix between knowledge and intuition.
I like to get inspired by www.funretrospectives.com, always adapting the format to the state and context of the team. For example:
For the first retrospective in a new team, I state the basis and basics of what a retrospective is, why we do it, then I lead a small warm up game/or put a question, depending on the maturity level, more in-depth (“Tell me some positive effects in your life from an apparent failure/bad thing”) or at a more general level (“What did you do today that made you feel good”).
As the team is new and the Team Pact, Way of Work, the team´s live-document, are still work-in-progress, I find useful to do a vaster retrospective, that would allow the entry of more points of view and open discussions, like the 4Ls retro (Liked, Learned, Longed for, Lacked). I personalize the board with images to encourage conversations and moderate so that everyone could have his/her voice heard.
Sometimes a classic format it may also be in a safe-zone, to understand where the team really is regarding the maturity level and see how it goes, still making the environment interesting from an aesthetic point of view.
For the mid-project retrospectives, when work is abundant, problems of many different natures surface, that the scrum master may even have or not idea about, I use metaphoric retrospectives (the Hot Air balloon, The Boat) or one that I really liked from Agile Coaching book of Lis Sedley and Rachel Davies https://www.amazon.com/Agile-Coaching-Rachel-Davies/dp/1934356433 , Emotiongraph.
I will detail the last one a bit, Emotiongraph (inspiration from Seismograph) — it is very useful when I may feel that things outside my radar happen or/and there is a kind of unknown tension in a team, or something goes wrong with the project or with the members of the team. You really need to prepare the ground for that because usually hidden emotions or beliefs are involved here, that may not want to get out. So, emphasize again the no-judgmental environment, the lack of perfection of every human being and that in spite of what we think about us we are ruled by emotions that we interpret on actual facts and we are all in a learning space.
So, we will put emotions and facts (happenings during the sprint) on the graph. All the team works on the X axis putting on it happenings during the sprint they remember, and on the Y axis the intensity of the emotion, negative (below) or positive (above the X axis). So, the team can talk about happenings or stories (if some stories occur during the conversation or on the graph) — with the collective memory we may talk about everything important that happened regarding facts with the attached emotions.
New things occur and we can see the “heart” of the whole team beating upon facts and events. This will get the team closer so that may work together in actions to take with full honesty, talk about the things openly.
Story-based retro — There are cases when the retro itself may be made only on 1 problematic user story or some important ones that reflect the work of all team so we could extract learnings from the way of work and the interdependencies. I used this kind of retro once and it was very useful for the whole team, and the learnings from it were applied to the overall project.
Ending of a project
At this point the team is a bit tired to do retros, they may even predict the way the SM will behave or do 😊, the novelty of metaphors passed, and everybody may be happy or sad for the project´s future ending.
I found it useful for the team members to take this time to settle the individual learnings/growths during the project for each of the members before the last retrospective in 1to1 coachings. If something was left unsaid in between them I encourage them to open up during the last retro, sometimes might be healing and full of learnings for all of them.
In the last retro I settle the ground to acknowledge the team members with their highest qualities and make a small validation game.
I leave a space for crazy ideas, what would have helped the project if we knew/would have acted from the start, what would they do differently with the learning that they now have, acknowledge the group learning, the individual one and focus on the positive aspects that they will, remember and integrate them the following project as good practice.
I keep the layout simple (the 3 standard cards) and discussions wide open.
I invite the team to celebrate the success — for sure in any project we will find one.
