I started my professional journey as a software tester 10 years ago, working in a small firm of around 15 people at a time when agile development was still a new thing for a small start-up. There were no retrospectives, no post-mortems, and no reflections on issues or actions – but I did gain valuable experience in terms of things not to do when undertaking product delivery, and how to deliver products in efficient ways which work for the organization.
Moving through different organizations en route to becoming a scrum master, I have been involved with not only agile software delivery but many other non-agile projects, client proposals, hackathons, webinars, UX planning and delivery, recruitment, and so on. Those experiences highlight the value of undertaking agile retrospectives for many areas of business.
Let us face the reality: not every project is successful, but in order to excel it is often important to step away from the endless delivery loop to reflect on past events and learn from them. Traditionally teams do reflect on failures and other issues in end-of-project sessions such as post-mortems but having identified and absorbed relevant learnings, it is obviously too late to fix those issues – and then those learnings often are not carried over to the next project.
Retrospectives (often also referred to as retros) provide an opportunity to reflect and adapt earlier and throughout the delivery lifecycle. I have seen first-hand how running retros in agile teams has enabled us to catch issues and act on them sooner, rather than waiting for projects or events to finish.
Derived from the world of technology and the agile methodology, retros are a safe space for the team to discuss what went well, and what did not, and determine learnings and action items/improvements for the next iteration. It keeps the team nimble and continuously improves delivery. Are such retrospectives only for Agile teams or only for product delivery teams? The answer is a resounding no!
Retrospectives can also be used to support agile-related activities such as team Check-In/Check-Out sessions, team building, filtering, Futurespectives, finding prime directives, or Energizers.
DIFFERENCE BETWEEN RETROSPECTIVES AND POST-MORTEMS
While they have the same goal, post-mortems and retrospectives have different goals and processes, meaning you will get different results depending on which you choose. The ultimate objective of a post-mortem analysis is to understand and study all the failures encountered after a project has been finished, to prevent these issues from happening again during future projects.
Sprint retrospective’s main purpose is to determine ways to increase quality and effectiveness during the projects. These check-ups are held at the end of each sprint (every two or four weeks) to understand what went well, which issues were faced, and how they were solved (or not). This information is reviewed by the project team and any action items can be followed up during the next sprint.
So, in essence, post-mortems and retrospectives differ in terms of timeframe, focus, and outcome. In my view, retros are more powerful, can be applied to many scenarios, and, critically, can prevent failures from occurring before it is too late.
Before undertaking a retrospective, it is important to understand the agile retrospective process and how it can also be adapted for non-agile teams.
A retro is part of the continuous improvement process of any team or organization. At the heart of each retro is the participation and contribution of each team member. Starting a retrospective habit with a new team helps build continuous improvement right from the start. However, that is not always possible, so it is always good to set up some periodic sessions (ideally every few weeks) where people can reflect on changes at regular intervals.
Everyone on the team can provide their views or thoughts about the Good, the Bad, and the Ugly (Improve). The team congratulate each other on the Good and discuss how to address the Bad and the Uglies. At the end of the session, the team agrees on the actions, ownership, and outcomes that will address the issues and deliver improvements.
i) Retrospective themes
The person who usually arranges or facilitates these sessions is called the Facilitator. It is up to the facilitator to use whatever themes and discussion blocks they think are appropriate for the team to use. From Post-it notes on whiteboard diagrams to fancy online interactive boards such as Miro, there are plenty of options available. Since we are now adopting the hybrid way of working, even interactive Excel sheets on SharePoint work as a mechanism to gather insights. However, my recommendation is to use the theme and tool which are easiest to use, and fun and interactive for the team if they are working remotely. Here is a link to some potential tools: https://geekbot.com/blog/19-best-online-retrospective-tools/
ii) Retrospective format/ideas
When the retrospective format is fun, the team feels energized and looks forward to actively participating. One format I use which is always loved by my team is FLAP – Future Considerations, Lessons Learned, Accomplishments, and Problem Areas – which covered all my team’s needs. To make your retrospectives fun and interactive, you should not be sticking to just one type. Always make sure you engage your team with various ideas to keep them engaged. You can find plenty of ideas here: https://www.funretrospectives.com/
Whatever format and theme you choose for your retro, ensure that you send out the agenda beforehand, so the team already knows what is expected from them.
iii) Follow through on action items
Identifying problems is easy. Finding potential solutions to those problems – not so much. Here are some tips to ensure action points are progressed.
Write your Action Items down 📝 – Too many teams complain about broken processes or issues, discuss ways to resolve them, but then never write down or record their agreed solutions.
Remember to be SMART 👌 – I have seen some action items such as “talk to project lead” – that are not good enough. Instead, make sure your action items are:
SMART: Specific Measurable Achievable Relevant Time-bound
One thing at a time ✔️ – You may have two to four takeaway actions from each retro but remember to focus on a single action item at a time. Resolution for each action item should be communicated with team members too.
Follow the energy 💥 – The team needs to be bought into action items, so commit to those items which generate excitement and energy in the room.
Not all actions can be worked through within a specific time frame or sprint. Even If your team does not follow agile ways of working, it still makes sense to prioritize your actions and define a timeline so you can track and resolve them.
SUCCESS FACTORS FOR RUNNING RETROSPECTIVES
As with everything, retrospectives themselves can present some challenges. I have listed a few key strategies to overcome challenges that – when addressed appropriately – will bring the best out of the teams.
- Greater engagement within the team- To ensure the team is engaged and interested, it is of primary importance that the facilitator should be unbiased and engaging. Facilitators need to create a safe environment where the team feels safe and secure in expressing their opinions and should also set clear expectations and assign a responsible person for each actionable item
- Better control over managing impediments that lie outside the team- At some point, teams identify impediments during the retrospective that are outside their control. What should you do? My first recommendation is to focus the team on what is within their control. Once you resolve those elements, slowly move on and outwards and identify what can help you to remove external obstacles
- Constructive criticism- No one likes to be criticized, so when we criticize any person or process it must be framed in a constructive way. Criticism without a suggestion often just comes across as complaining
Based on personal experience, a successful retro – whether involving agile or non-agile teams – needs two key ingredients: a safe environment where people are free to express their opinions, and beliefs in the process. A quiet team will result in a lackluster discussion, bland insights, and an uninspiring meeting. Accordingly, the facilitator’s role is to get the team talking, ideally sharing specific and deep observations that the team can examine together to form interesting discoveries.