Here are some very simple rules of thumb regarding the planning of retrospectives.
Duration of Retrospective
The duration of a retrospective event depends on its frequency and the number of people participating. The rarer you have a retrospective, the more things need to be discussed and addressed. The more participants you have, the more time goes for sharing, alignment, coordination and achieving agreements. Here are approximate recommendations for the retrospective lengths (not based on any scientific research but purely on my experience).
At the same time, the more frequent and regular retrospectives, the more sustainable improvements are, but if they are too often, then we might not have time to see the results of our actions. I believe the sweet spot is between 2 and 4 weeks, depending on the team structure and how rapidly the environment changes. The more dynamic team is and the faster the environment changes, the more often retros should be, in some cases even daily.
Choosing Activities for Retrospective
With so many options for retrospective format and possible activities, how to decide what to select?
First, define the goal of the retrospective, what would be the most important for this particular team for this particular moment, for example:
- The team is new and needs more low-risk team-building activities
- You feel that the team is becoming complacent and probably needs some status quo challenging
- There is implicit or explicit conflict in the team that needs to be addressed.
- A major change has just been released, and we need to review our lessons learned (“post-mortem”)
- Some major initiative is about to start, and we need to review our readiness and align our expectations (“pre-mortem”)
- End of the year retrospective with looking back to get proud of ourselves and forward to motivate ourselves for new achievements (the whole team New Year resolutions)
- or just usual, incremental improvement, type of retrospective
And then you can start thinking about the activities that can support this goal – either choosing them from a site like Retromat, or your own collection (you can collect your favourite activities on Miro board, for example, divided by the retrospective steps ) or inventing your own – after you facilitate many retrospectives, you are able to synthesize activities you have done to new ones.
Currently, if I don’t have the idea right away, I browse through some collection of activities for inspiration, and then I usually come out with some different idea based on what I have seen.
Tip: Try to keep a catalog of all the activities you have done so far, don’t rely only upon your memory.
Tools For Retrospective
The most important thing about a tool that you use for a retrospective is that it should not define your retrospective. First, create the plan for the retrospective based on your goals, and after this, think about how you can adapt the tool you have for your plan.
Some tools might be more convenient for retrospective conducting than others, but you can do practically any activity with any tool; your creativity is your friend here.
The best tool ever is just a flipchart (plus sticky notes and markers) – use it if you have the luxury of all the team members being in the same room. Use digital tools only if you are in a remote or hybrid setting.
The best digital tools are all types of digital whiteboards, the universal ones, like Miro or FigJam, or you can use whiteboards built-in into other tools, like MS Teams or Zoom (surprisingly few people are using it or are just aware of them), or use a digital whiteboard specialized exactly for retrospectives, like MetroRetro being a really handy, feature-rich and easy to use tool for the retros.
And even with less visual tools, like Confluence, you still can run great retrospectives, using its feature of collaborative editing and your creativity! You can even do it in Mentimeter.
Divide participants into smaller groups
Some people are more talkative or more dominant than others, some people are shyer, some people are less confident with expressing their opinions, especially if in a foreign language, and a huge number of people in the software development industry are far away from being extraverts – and we still need to ensure having opinions of all of them included to the decision we make as a team. And for achieving this, dividing the team into smaller groups or pairs helps a lot.
You don’t need to do it for all the activities; it might be only during one or two activities, one time pair, another a small group – people are less tired when setup varies regularly. You should also try a great Liberating Structures 1-2-4-All structure, a truly collaborative method.
Dividing also works great for scaling retrospectives – if you have a really big group, 20-150 people, you can facilitate such a retrospective only by dividing the participants into smaller groups (which can also be divided into even smaller groups) and then have inputs from down to the top, consolidating all the voices together.