It's better to have a bit of knowledge about Scrum/Agile before reading this but it should be understandable nonetheless :)
Disclaimer: I'm not a certified Scrum Master (CSM) and I have never gone through any certification of sorts. However, I have some knowledge of Agile methodologies that I got by reading some books about the topic. I also had the luck of attending meetups with people WAY MORE experienced than I am on handling teams, and people.
I have also been a Scrum Master myself for 3-4 years, a Scrum Master from the trenches. I learned on the job and I think there are some things that, even though obvious looking, are really gotchas when looking at them in hindsight.
That's exactly what I'm trying to convey with this post.
A retrospective is a meeting within the framework of Scrum in which the whole team takes part and discuss points that occurred or relate to the current Sprint.
Agile can be seen as a framework focused about delivering value to the client in a flexible way. What this means is that, in every iteration of the process of building whatever product you're aiming to have, the team will deliver some value to the client.
This is opposed to other older ways of working where you would work for X months/years on something, and finally deliver a final product at the end of this period.
Sometimes, priorities will change and thus, work for our team will too. This might require your tasks to change, re-prioritize or even drop. We could say it's an ever changing product in a way.
In the same manner, Agile applies to the same process that the teams and organizations follow. We want to tweak it as we go so we can adapt to whatever is happening within our team and from the side of the customer.
The simplest way I can put it is:
A retrospective is a meeting that allows the team to improve and react to situations and changes.
For that same reason, the frequency in which you have them is important. The shorter the iterations, the faster you can react to a problem and hopefully solve it.
It typically involves a phase where the team members will write down the topics they want to discuss / highlight, followed by a phase in which the whole team votes on what topics from the pool they want to address in this meeting.
After that, the team discusses the most voted topics, and extract action points to be worked on during the next Sprint and reviewed on the next retrospective.
It's better to address those points at the beginning of the next retro, rather than leaving it for the end of it since usually time runs out before you tackled them if you do it last.
It's important to understand the value that the retro provides.
You might not be needing it this Sprint, but there might be someone else who is struggling with something and needs to discuss it.
It's a very important tool and should be understood as such. Engagement is very important.
People looking at their phones or working while a retro happens don't show much respect to others' concerns. But that's a general remark for every meeting, really.
Additionally, it should be a safe space for the team to discuss sensitive topics.
You don't have to wait and explode at the retro. You should always try to rely on good communication to avoid these kind of situations. You should encourage talking about problems whenever they occur.
However, sometimes you need a bigger space (time slot) or more people involved in a discussion that you can get at the moment the problem happens. Retros provide a safe space to discuss bigger issues in a moderated manner.
There are many books about Scrum and Agile methodologies, each of them prescribing different things. It doesn't matter what sub-religion you follow, just make sure you give enough space for issues to be addressed.
It's better to start with too much time, or too frequently, and dial that down when you feel the team / processes have matured enough and not so much value is coming out of those meetings.
Want a prescription? Start with one retrospective per week per team. See how that feels and adjust accordingly.
When it comes to people expressing feelings, it's easy that meetings get long.
It's very important to timebox every step of the Retro so that you make sure you can successfully conduct one and get the actionable items at the end of the meeting.
The most common Retro usually follows this steps:
You can keep the 5 minutes left of that hour as a buffer for any of the steps. It can also be that one step takes shorter than expected, just jump onto the next one then.
Important to address those and if they haven't been solved, or are a longer running issue, move them to the next retro to not forget about them.
Ideally, people would come with their topics prepared, or having thought a bit about what went well/wrong during that Sprint. It's not a bad idea to encourage people to write down those things along the way, whenever they encounter them. It really helps in tackling things that people considered important but sometimes would forget otherwise.
Usually, you'd give 3/5 votes per team member and it's important to make them aware that they can use ALL of them on one topic if they want. Also important, do NOT vote on "positive" topics. Just take a couple of minutes to go over them on the slot for further explaining topics if you want.
Allocate 10 minutes per topic. Reserve 3 to 5 minutes at the end to extract action points. This is, of course, variable. If this Sprint there's a really important topic, or there are less topics to discuss, you can allocate more time per topic. It's important that the topics that are chosen to be discussed CAN be discussed properly. Otherwise, the retro can have the opposite effect, that is generating more frustration because it doesn't solve or address the issues that exist on the team.
Wow, that was a long post, thank you so much for making it to the end.
I hopefully brought you at least one or maybe two little ideas that you can take with you to make your retrospectives smoother and more effective.