They say hindsight is twenty-twenty. Things always seem to fall in place when looked back upon – the causes, the affects, the problems, the solutions, and more problems. The key is in learning from it and using that learning to guide our actions in the future. Agile has formalised this wisdom into a meeting called the Retrospective.
A Retrospective (called retro in short) in Agile terms is when you reflect back upon a certain period (say a Sprint or a Release) or the entire project (in case of project-end retrospectives) and see what went well, what could have gone better, and what experiments to try out in the next sprint / release / project. Some key questions could be:
- What went right? What went wrong?
- What could have been done better?
- What challenged / excited you?
- Any events / activities / tasks that you would want to highlight.
- Your overall feeling about the sprint.
Each team member involved with the project (even the client if possible) sits in the retro. There are various ways of conducting a retro but the book Agile Retrospectives by Esther Derby and Diana Larsen offers a structured approach:
- Set the Stage
- Gather Data
- Generate Insights
- Decide What to Do
- Close the Retrospective
In a nutshell, the team highlights issues (both positive and negative) they want to raise. Then the related issues are grouped together and thrashed to arrive at the root cause. The objective is to look for causality so that negative issues could be avoided and positive ones reinforced in the future. It is possible that some of those negative issues were the direct result of individual actions. However, the team never falls into the trap of blame-game and no fingers get pointed at any individual. The principle behind this is the Prime Directive framed by Norman Kerth – “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand”.
A retro is a great platform to uncover those feelings / events that may be hampering the process. In Scrum, whilst the Sprint Review is an opportunity to implement the inspect-and-adapt philosophy to the product, the retro does so for the process. If a team continues to hold retros in spirit and word, it would identify actionable items at the end so that the process is improved and the impediments uncovered are removed or the experiments outlined are accomplished. It helps the team vent out feelings of frustration / sadness without making anyone look bad. It also lets the team highlight positive steps performed by individuals that helped the team. Most importantly, because Agile is a framework and allows you to tweak things without compromising on the principles, the team can identify some hypotheses it might want to test in the next Sprint / project. This helps the process to evolve and strengthens it further.
Seeing the power of retros and the value they bring to the table, a lot of teams have started using them. I have seen even support staff (HR / Admin) use retros to help them improve their effectiveness and chip out at their weaknesses.
Summarising the above, by holding regular retros, you can make identify areas of improvement that maybe plaguing your team performance or strengths which can be leveraged in doing a better job.