Retrospectives are a great way for project teams to look back at their achievements and learn from their mistakes. Here’s what you need to know about retrospectives and how to conductive effective ones.
Do’s and Don’ts: How to Conduct Effective RetrospectivesLinh Tran, Thursday 08 December 2016 | Reading time: 5 min.
“The successful man will profit from his mistakes and try again in a different way.” - Dale Carnegie
When you think about retrospectives, you think about agile project management. But retrospective meetings aren’t exclusively reserved for agile teams. Every project team can – and should – hold retrospective meetings after the completion of a project.
What is a retrospective?
A retrospective is a meeting that happens at the end of the project or at the end of each scrum sprint. Scrum teams work in iterations, it means that they have to deliver a potentially releasable product increment. After every sprint there’s a sprint retrospective. It’s an opportunity for the project team to look back at what they have achieved during the last sprint, what went really well, and what could be improved. The focus is not on how the product or deliverable could be improved, but on how the team can collaborate more effectively to generate better outcomes. Retrospectives are great for teambuilding as it enables teams to understand each other better and facilitates better collaboration which in turn leads to improved productivity. The emphasis is on continuous improvement and change, instead of blindly following the same old procedures and processes.
Do’s and Don’ts of effective retrospectives
It can be difficult at first to conduct effective retrospective meetings that bring about results. It’s important that the team members don’t feel as if the meeting is just a waste of time, but that they got something of value from it. They should understand that retrospectives are an important part of the project and at the end of the meeting they should feel that the team accomplished something. Following these Do’s and Don’ts will help you achieve this goal.
- Celebrate successes and congratulate the team for a job well done. This will improve team morale and motivate them to deliver even better work.
- Have a moderator who leads the session. This can be the scrum master or a neutral person (external or internal).
- Have a clear goal for each meeting. This will help the team stay on topic instead of getting sidetracked.
- Determine the key issues you want to address in the retrospective. Don't try to tackle every issue at once, but identify the most important issues you want to resolve in each session.
- Focus on the team and their relationship, not on the product. Retrospectives are there to help the team find ways to work better together.
- Establish an environment in which every team member feels at ease to share their opinions. Make sure that everyone on the team is involved in the discussion and does not have to be afraid of being jduged.
- Identify the actionable items for the next sprint. The function of retrospectives is not just looking at the previous phase, but also talk about the next steps.
- Don’t end a retrospective and never think about it again. It’s important to keep track of previous retrospectives and whether you were able to achieve the goals you have set.
- Don’t let the meeting be too negative. Retrospectives are not there for the team members to complain, it’s about resolving issues and improving the teamwork.
- Don’t go into the meeting unprepared. Agile is all about flexibility and being dynamic, but that doesn’t mean that you should be unprepared. It’s difficult to come up with spontaneous ideas, so encourage the team members to sort their thoughts before the retrospective (see Brainwriting)
- Don’t just focus on improving at all costs and pressure the team to implement all ideas that come up during the session. It takes all the fun out of the exercise and can hamper the team’s creativity.
- Don’t let outsiders attend the meeting. Remember that retrospectives should focus on building the team’s relationship. Having the product owner or another executive in the room will make it difficult for the team to truthfully talk about mistakes or concerns.