Retrospectives are an important part of any engineering culture. Whether your team is actively working on sprints and iterations or just periodically using the time to check-in, allowing teams to have set times where they look back and reflect is vital for team healthy and employee morale. One of the things I like most about retrospectives is that there are a variety of methodologies and ways you can run them. For example, if you are a small team of developers mostly working on individual projects, you can run retros together to reflect on individual challenges of your project and incorporate that into thoughts and reflections on the team culture as a whole. Or if your team is large enough, you can run regular retrospectives just with your immediate team.
There are also literally hundreds of different methodologies and ways to run retrospectives. I suggest rotating who leads them (which also provides a valuable training opportunity), and, if possible, allow whoever is running the retrospective to pick what methodology is used. Often times I think teams will find a methodology that works for them and that will be chosen regardless of who’s running it, but it’s nice to allow for the option to “mix it up” a little bit. My two favorite sites for retrospective ideas are here and here.
Finally, think about how to make retrospectives remote-friendly. For example, use google docs or trello boards, use collaborative whiteboards, have everyone log in from their own computer, etc. Just because a methodology is presented with post-it notes or isn’t a remote-friendly format, doesn’t mean you can’t change it to be so.
I think one of the most important aspects of a retrospective is that teammates respect one another and respect what each individual is saying. If you have a “bad influence” or detractor on your team, one way to help ensure they respect the other teammates is to use one retrospective to “create a contract”. This often happens at the beginning of group experiences when you want expectations to be set for how the group will behave but don’t want to be the manager or individual that says “here are the rules”. In this approach, you start by saying that you want these sessions to feel as comfortable and productive as possible and so it’s important the team comes up with the rules they, as a group, want to follow. Generally something about listening and respect will be suggested by someone in the group and agreed upon by the rest.
I’ll be posting more tips like this and full outlines of retrospectives and learning workshops, so keep a lookout.