This time I’d like to share a secret of how me and my teams continuously improve, identify the root causes for the issues, effectively mitigate risks and adjust processes according to their needs. We owe this superpower to Agile Retrospectives.
Even though this tool has proved its effectiveness multiple times in real life, I keep observing team leaders and project managers who either don’t schedule retrospectives at all or conduct them in the wrong and ineffective way. In this article, I will try to convince you to give it a try and derive from it a real value for your team, your department, and even your company.
Start with “Why”
- PMBOK guide states that lessons learned should be gathered at the end of each project. From my own experience and work on many different projects, it is a little bit too late. Lessons Learned provide an awesome input for any similar projects which are in the pipeline (remember, that one of the recommended actions, when you start a new project, is to check if similar projects took place and check for the lessons learned). However, if it is done at the very end (IF is it done … from what I have observed in real-life projects, people rarely do it due to lack of time), imagine how’d you feel if you could have improved something already, if you have identified good practices much earlier. Maybe you’d have changed the history of your project 👆
- Imagine how much time you could have saved if you and your team identified immediately the root causes of the issues. There is a very high chance you could have avoided spending time again and again on the same topics, saved your time and the time of your team from facing the same old stuff.
- Your boss will be happy because he/she pays you to solve problems and not to come with them to them. When they see how you and and your team tackle issues and continuously improve, you’ll become known as a professional “issue-solver” and “preventer” 😀
- Your customers will be happy because they will see that you learn from mistakes and avoid repeating them again. Nothing disappoints customers more than facing the same issues multiple times. Moreover, I have conducted retros with customers and teams together and it was amazing to see how this helps both sides to understand each other better.
- You can use it as a super-effective communication tool for team integration. It helps your team members to open up and communicate what goes well and what could be improved, enhance their cooperation, see what they have to face and where you, as a servant leader, can help.
- You and your team need to understand what went well. People also need encouragement and have a helicopter view of what works well. Make them realize it and appreciate each other’s contribution and effort for common success.
- If something really goes well in your team, it is an opportunity to enhance further and share with others. Sharing is caring. Also, you will earn yourself a bonus of being a leader who contributes to the success of the other teams and makes a contribution to the company you all work for.
- Agile retrospectives in Scrum are done at the end of each Sprint, so it is “hard-coded” into the process. In any other type of project or initiative, you decide how often you want to conduct them. But consistency is what transforms average into excellence.
To be honest, I have many more reasons to prove why retro sessions are so important, but if those above are sufficient for now – keep reading 😉
Key considerations
- Set the stage: It is very important to prepare a short agenda for the retrospective session and share it in advance. People need to be prepared to what is about to come, especially if you do it for the first time. Later, when everyone gets used to such types of meetings, it will be smoother and less preparation will be needed. These sessions will become your team’s “second nature”. The example of such agenda can be as simple as setting an objective (Sprint XX retrospective, Project milestone XX retrospective etc), time-boxing and sequencing the activities such as collect the input from team members (15 min), group ideas (5 min), vote (10 min), discuss and define action items ( 30 min).
- If you want people to play by the rules, you need to explain the rules. Usually the process looks like this:
a) Input: you ask participants to provide their inputs. I personally do it in advance, so that people have time to think. If you wish, you can do it during the retro itself and dedicate 10-15 minute to collect the inputs.
b) Grouping: review the board and group similar inputs.
c) Voting: ask your team members to vote for the topics they think are most relevant (it is neccessary to prioritize topics, if time allows you can cover even all of them).
d) Action: define what will be the next action item for each topic you discussed and put it in your backlog, in to do list or into your plan. Scrum recommends to identify 1 top priority action point and take in into the next Sprint. I personally try to work on each action item but allocate it wisely to consider timelines and priorities.
- Keep it simple with 3 standard columns: 😊what went well, 🤦♀️what went wrong, and ✔what is the next action item. Sometimes, I add an “idea” column so that people feel free to submit their ideas for any improvements.
- Keep it anonymous. It takes courage to say openly what does not work. And it takes courage to accept the mistakes. But it also takes time till team reaches such a state, that they speak openly about goods and bads.
- Act upon each identified action item. Look, it makes sense to conduct retros if you are going to do something about topics discussed. So make sure the action items from retros are actually done and implemented.
Are retros only for agile projects?
Of course not. I’ve been conducting retros for already more than 2,5 years in different projects and my only wish is that I have learned about them earlier. I used retros during complex cloud infrastructure migration project and we conducted lessons learned sessions every 2-3 weeks, even though it was not a software development project. But regularly conducted sessions helped us improve the migration process and productivity up to almost 30%. I conducted retros on a regularly 2-weeks basis with my scrum teams. I also had retros on a regular monthly basis with my team, where we had kanban. I recommended the approach and conducted a session within the Project Management community at EY when we had to look back and see what worked well, what did not, collect ideas and identify action items. As you can see, if you know how to retrospect, you can apply it to many initiatives within and outside your company and derive value immediately.
What tools can you use to conduct retros?
Nowadays there are so many free and paid tools, that you don’t have to worry about any specific one. Tools I have worked with and can recommend I list below. Many applications offer a great variety of features which help you be very effective and productive during retro sessions. One of the #projecthacks is that you can export the retro inputs into a word file or pdf, distribute them to additional stakeholders, and store them as part of the project documentation. Imagine how valuable it could be in the future?!
- Retrospective extention in Azure DevOps (I loved this one❤)
- Easyretro.io. Just a nice one.
- Mural.co. It is in general a great tool to get familiar with. I conducted couple of workshops with it and must say – I am impressed. It has dot voting feature, many templates including the one for retrospective session and will come in handy in general.
- MS Teams Planner or similar solutions (Trello). Even if you are limited with available tools within your company, you can use MS Teams planner or Trello, create famous 3 columns for retrospectives, provide access to your team and voilà.
Any cool books to read?
I’d like to recommend 2 books 📚 on the topics, which might be helpful to cover the theory. But I personally advise you to start putting your new knowledge from this article into practice and decide now when you want to schedule your first retro if you don’t have it yet. You will be amazed by the output.
Book 1 “Agile Retrospectives: Making Good Teams Great” by Esther Derby, Diana Larsen and Ken Schwaber”
Book 2 “Improving Agile Retrospectives: Helping Teams become More Efficient” by Marc Loeffler.
I hope this information was useful and you will be effectively using retrospective sessions in your projects. If you know someone who can benefit from this information, please share. If you have additional useful insights about retrospective sessions and interesting ideas, please share, I would love to hear about them. Let’s support each other in our continuous improvement. Sharing is caring!
