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, no reflections on issues or actions – but I did gain valuable experience in terms of things not to do when undertaking product delivery, and around how to deliver products in efficient ways which work for the organisation. 

Moving through different organisations 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’s 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, what did not, 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, in order to prevent these issues from happening again during future projects.

• Sprint retrospectives’ 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 where 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 occurring before it is too late.

Retrospective process

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 organisation. 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 in the team can provide their views or thoughts about the Good, the Bad and the Ugly (Improve). The team congratulate each other on Good and discuss how to address the Bad and the Uglies. At the end of the session the team agrees the actions, ownership and outcomes that will address the issues and deliver improvements.

i) Retrospective themes
 

Person who usually arrange or facilitate these sessions is called 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 adapting 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 also 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 energised and look 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 team already know 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 is 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 single action item at a time. Resolution for each action item should be communicated with team members too.
• Follow the energy 💥 – The team need to be bought into action items, so commit to those items which generate excitement and energy in the room. 
  In reality not all actions can be worked through within a specific time frame or sprint. Even If your team doesn’t follow agile ways of working, it still makes sense to prioritise your actions and define 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 which – when addressed appropriately – will bring 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 safe environment where the team feel 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 criticised, so when we criticise any person or process it must be framed in a constructive way. A 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 belief in the process. A quiet team will result in a lacklustre 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.