I can't categorize any retrospective as a failure or success. I think all retrospectives are successful because the team gathers to talk and they identify what went well in the Sprint or what can be an improvement for the next one.
What I do think is necesary for a complete and successful retrospective, is to go deep and find the problems that are causing a real pain in the project and to define the solutions for them.
Here are my 5 recommendations for a successful retrospective:
1- Bring the main issues to the table.
When the scrum team doesn't talk about the real problems of the sprint and they just mention simple things, small problems, sometimes is because they might feel guilty for something or don't want to point at someone because it might lead to a confrontation.
In this case, is important that the Scrum Master guides the team to get this problem to the surface, that they ask the proper questions, identify and go deeper in that subject. In the end, the idea is to solve things as a team instead of blaming each other. In Scrum teams, the failure responsibility is the team’s and not someone in specific.
2- Make the improvement items measurable and assigned to someone.
Each improvement that is defined in the retrospective needs to be something that can be measured, and not something vague. For example: “Have more commitment to the project” but, what does this really means? This is subjective... it could mean that the team will have the deliverable on time or that they will test and make sure they don't have any bugs. Also, who will be in charge of that item? It can be one person, a couple of people, or the whole team, but it's important to make sure that someone will take care of that and define when is going to be delivered.
We can use the SMART acronym to set the characteristics of an improvement item:
Specific – Well defined
Measurable – That has a quantitative indicator of progress
Agreed upon – Who will be in charge of this task
Realistic – Make sure that the results will be achievable
Time-related – When the task will be achieved
3- Doing a follow up after finishing the retrospective.
The retrospective is finished, the team made fantastic commitment to the improvements and they go into a new sprint. In the next retrospective the same problems persists, nobody did what they committed to. Who was responsible for this? The whole team. There are a lot of ways to manage this. What I do is send the problematic items via email with the SMART features so everyone can be on the same page. Then, every couple of days, I double check with the team on where we are with the items. Another thing to have in mind, is trying to be more visual, put all the items visible for the team, ideally on their task board and check their status on the daily meetings. There a many ways to do it, you just have to be creative!
4- Make everybody participate.
The opinion of everyone in the team is important and should be taken into consideration. The Scrum Master should facilitate that everyone participates and expresses their concerns. When this doesn't happen, the retrospective only focuses on the extroverted members of the team, so the decisions made in the retrospective might not be representate well for all the team.
5- Check the quantitative statistics of the project.
It's important to know how the team feels regarding the project or what are the technical challenges they have to face, but it's also important to check the quantitative results. Are they finishing the sprints on time? Do they have bugs? How many stories do not pass? Does the client review the stoppable product? Does he have feedback?.
It's important to review these items in all retrospectives, and as a Scrum Master I try to have that information before the retrospective, and see what the team have to say about the results.
In summary: a retrospective is an important way to make improvements in the process and the team, but if it’s not well managed, it will be just a meeting of catharsis. Be sure to get to the root of the problems, devise a plan and then commit to make improvements! :)
Chief of Continuous Improvement at Tekton Labs