I’ve led a number of teams building software and I’ve experienced some things. I spent a number of years following the by-the-book rules for running a retro as described in Agile Retrospectives: Making Good Teams Great. That book is long out of print but you can pick up a used copy cheap. You can also google the title of the book and easily find PDFs so it seems that the original publishers aren’t particularly worried about people accessing that.
Most software teams have 4-6 people and the book is written to attempt to be valuable to people running regular meetings for small teams like that or running large meetings for whole organizations. The book has a lot activities that you can use for running a retro and it can be nice to shake things up by running new activities but it also means you can spend a lot of time explaining the activities and their specific value. Having a retro every 2 weeks we had a lot of practice and I found that we started to gravitate toward specific activities that people understood well and were able to cut directly to the issues and that level setting and ice breaker style activities became less valuable.
The variations of the “Liked, Learned, Lacked, Longed For” activities quickly became favorites and for a team that is working well and has built trust and feels psychologically safe I have had a lot of success with only doing one activity in that style and having conversations around themes and assigning action items after the retro. Those specific four categories aren’t perfect in every situation so modifications make sense because “Lacked” and “Longed For” can have a lot of crossover.
If you have appropriate space for the activity doing it in person with a bunch of Post-it notes on a whiteboard is great. The interactive nature of things helps activate your brain but it removes any amount of anonymity if you want to give some critical feedback and makes capturing the output of the meeting challenging. Most meeting spaces don’t have appropriate room because they are built for a bunch of people to sit around a table and talk to a big TV on the wall.
Where we landed right now is using Retro tool at https://www.retrotool.app as our source of truth for performing retros. It has sections for “It worked well…”, “We could improve…”, “I want to ask about…”, and “We need to do…” so it captures the core of the data that you are looking for in a retro. It is fully hosted online and everybody interacts with it on their laptops so it works fine in person or remote. You can contribute fully anonymously and during conversation give more insights if you choose. It has an added bonus that if you continue to use the tool that unfinished action items roll over in to the next retro. You can put a password on your retro or if it’s public somebody would have to brute force guess the UUID for your session.
Surprisingly the hosted version of Retro tool is totally free and claims to be “totally anonymous and doesn’t track or store any personal information.” The source code is freely available but lacks any license so legally that means you can read the code but you are not permitted to run it or edit it or distribute it. So it’s a bit of a strange situation. The tool is free but it costs the people running it some amount of money and there doesn’t appear to be anyway to contribute financially to the project so in theory they could decide to shut it down at any point. In theory you could use the available source code to host your own version but that’s theoretically not legally. I don’t love being dependent on a tool with level of murkiness but I also have found it to be extremely useful.
Slightly related the planning poker tool that I found to be the least offensive is Pointing Poker. It is a bit rough about the edges and we’ve had times that the system was offline but it’s straight forward and free and has a proper terms of service and privacy policy and has a donate button so that if you want to support the developer you can.