The retrospective meeting is one that everyone thinks they want, but often times people don’t actually do. It’s extremely important though, after you do something big, to pull everyone back together and ask, “What worked well? What needs improvement? What should we never do again?” The difficult part to having a retrospective meeting is doing it in a way that really stresses that the point of the meeting is to grow and improve and not to blame.
We see different types of retrospective meetings across multiple professional fields. In the healthcare world, they call them M&M – morbidity and mortality. When you’re a resident, every week you have to bring the thing you messed up on and present it so everyone can learn from it. “Look I did wrong and how can we learn from this?” They then rip you apart on it. In the business world, particularly software development, retrospectives are much different.
You cannot have an effective retrospective meeting if people are afraid to speak up and talk about issues. We aren’t pointing fingers; we are looking to improve. You have to approach it in a way that stresses the idea of having people park their buses so no one gets thrown under them. Each person needs to find a constructive way to say, “So and so needs to do a better job.” or “We need help in this department.” If you want to get people to speak up, you have to make it feel like a safe and productive space to do so.
Find constructive ways to identify problems and issues. There are a variety of approaches to this. You can use the post it note method, where each person is required to write down three things that need improvement. Then each person will have to read their thoughts aloud. You can have people submit thoughts anonymously. It’s all about continued improvement and it is an extremely important part of the development process. Looking back is a perfect way to find out things that have gone wrong so far and to identify actions for improvement moving forward.
The three main questions you want reflected on are: What have we done that has worked well for us? What have we done that has not worked out well? What actions can we take moving forward to improve? Once people feel comfortable sharing their thoughts, you can generate some great insights. A good approach is discussing successes and also issues that came up. Decide what to do by coming up with ways to remedy the issues instead of assigning blame. Create goals and tasks that can help these to not become issues again in the future.
Retrospective meetings like this should include everyone from IT to QA to marketing to training and everyone in between. The whole business unit has to be present to have a true retrospective. Otherwise, you’re excluding perspectives that may have valuable insights. Every different part of the business unit has a unique perspective on a project. The feedback is important to hear. Outside perspectives are important to consider.
What do you think the value of a retrospective meeting is? Is it possible to have an effective meeting where people interact without pointing fingers? Any tips to a successful retrospective? Comment below!
