They’re not effective unless people actually do the follow on actions and create change. Otherwise they are just bitch sessions.
They also can suck because the fundamental problems are not solvable by the group of people in the meeting. They’re endemic to the organization and at best you can work around those issues.
People also are hesitant to discuss some elephants in the room, or have a sense of learned helplessness about certain topics.
One issue I've seen since then regarding retros is that they'll fall into two extremes. The rare one is that retros are just fun recess times that nobody gets anything out of besides doing doodles and ice breakers. The other one is that teams will try and be very action oriented and find concrete solutions to concrete problems, but will not have the emotional maturity to address difficult topics, so they're either avoid them or turn into screaming matches.
You need to feel somewhat close to your coworkers to be able to bring difficult topics with the certainty that others will know you do it for the right reasons and that you're all trying to work towards the same goal of making work more effective, pleasant and satisfying. Teams that never work on the closeness of their members cannot address important issues. You need the doodles, the inside jokes, the team spirit to be able to do that.
But you also need to have a mastermind to spot issues and then figure out ways to role play and brainstorm around those in a way that feels like playing, but ends up providing the team with actionnable solutions.
At the company i've worked at, I've had to sometimes do tasks that were really not my duties (data entry, QA work) because it was the most important thing that I could do for the team. I happily did it because I felt like it really was our project, that I'd be bringing value to customers and the company in doing it, and that our product would be better with that work done by me. I'd stay late if there was a problem I could possibly assist my coworkers with, even if I stayed for nothing or could only contribute through naive questions to try and get neurons firing... But we were a close team, despite having different roles and seniority levels, and we were all very happy to do what the project needed.
In my current company the sense of ownership isn't as important, people don't know each other as well (the team also is larger and with more turnover) so it's made of smaller groups of kinda close people.
In a perfect world everyone in all teams would be a trustable high performing dev and there would be no need for any lubricant to make the machine work smoother, but the reality is that the majority of us have pet peeves, quirks and shortcomings, the group can be a good way to mitigate those, as much as processes and methodologies, but having both is what will get you the best results, and I think this is something that is overlooked by many teams.
Usually we were knocking ourselves out to complete the sprint and just wanting to go home. Feeling exhausted the last thing you want to do is talk about the sprint more, particularly when there are the common communication pathologies which make people doubt they are really being heard.
We use a trello board with the following headings:
- what didn't go well
- what went well
- ideas / discussion points
- show 'n tell
Everyone spends the first 5 minutes putting items for things they want to talk about. Then we go through them in order.
There's also an actions tab where we put anything important that arises during the retro. Those usually get turned into tickets or future meetings by the manager.
Usually there are 4-5 things that we discuss over 45 mins to an hour.
As far as I know everyone's happy with how they work (including me).