6 suggestions that can save your next retrospective.

Even if the circumstances that involve teams may not be that different (we're all just creating software, after all), the ways those teams cope with them really changes, depending on how safe they feel within the team, their seniority or the general situation of the project.

The retrospective doesn't need to fell absolutely comfortable after all. As a team evolves, also evolves it's interactions. The subjects of conversations deepens and the room for conflicts widens. But, again, that's perfectly ok. It's like going to a party were you don't know anybody. At first you'll talk about shallow subjects like the weather, but as you encounter friends, much touchy subjects arise, like politics, religion or feelings. Those conversations are the ones you want your teams to have.

I don't want to dwell too much in negative aspects, but instead I'd like to focus on a couple of suggestions I always give, to have better retrospectives.

• Always start acknowledging if you completed or failed your sprint. Do this first as it will set the tone of the conversation. If we succeeded, then let's try to find what we did right and continue with that. If we failed, try to understand the real whys by doing some root cause analysis.
• Review the action points decided on the last Retrospective. Every team should have at least one action point focused on improving something on the development process. It's a good idea to review what was decided and how the team followed up on the promise they made to improve. The Scrum master should help the team decide if this objective was accomplished and can start working on something else, or if the team still needs to complete this improvement objective.
• Focus on the team. I've seen it more often than not, teams that consider that all their problems are caused by external factors they don't control, so they ask their Product Owner or Scrum master to communicate this to the involved external parties. A good retrospective should always be about the team and what the team can do to improve itself.
• Don't try to solve ALL the issues that arise. During a regular sprint there can be two or three situations that are remarkable, and a lot of little things that could've been done better. When the team members are presenting their points of distress, is good if they only explain them briefly and group them with similar situations that their peers already presented. Avoid discussing solutions for each and every problem. The Retrospective should allow the team to recognise the really important ones, and only for those there should be a discussion on how to solve them.
• If possible, make it an standing Retrospective. Standing retrospectives tend to have a different energy about them, with people discussing a topic next to a board or glass window, where post-its or annotations can be made. This is completely different where a sitting Retrospective leads to a more laid back, non participative meeting.
• Always end up the meeting with action points. Independently from the retrospective method the team chooses, it's very important to end up with several action points that the team will address during the new sprint. This is the final goal of every Retrospective. Usually three action points is a good number, but consider this seriously: Is the team capable of dealing with this amount of action points during the next sprint? Sometimes is even better to just work on one action point at the time, it that means a more focused team.

These suggestions are not silver bullets on themselves, but if you are a Scum Master or a Team Lead and want to help your team to be better every sprint, then try to implement the ones you aren't already doing and see the difference.