Retrospectives are an integral part of every project we undertake, as well as a key ceremony in the Scrum lifecycle. Agile principally stresses the need to perform periodic meetings to reflect on the functioning of the team, their processes, and actions and try to improve their shortcomings, so retrospectives are essential. The team gets to look back on their work and answer three key questions: What went well? What did not go well? How can we improve?
Even if agile teams perform retrospectives as a regular part of their project lifecycle, there are a few common mistakes they may be making due to a lack of understanding, perspective, or communication, and these mistakes can prevent obtaining the maximum benefits of the retrospective.
Here are five common mistakes and how to avoid them when doing your retrospectives.
1. Not doing retrospectives at all
Agile teams stressed with deadlines and tasks tend to miss out on doing a retrospective meeting. Even if they begin with it, they soon lose the drive and skimp out on performing retrospectives periodically, thus missing out on the real benefits of seeing themselves actually improve.
The first important step is to decide on a suitable frequency to perform retrospectives, such as every sprint, every week, or every release, and then follow through on actually doing them.
2. Doing retrospectives too infrequently
The premise of retrospectives is to have the teams improve over time by looking back at their own successes, failures, and mistakes. When we answer the questions about what went well and what went wrong in the past sprint, iteration, week, or release, we automatically also set a goal for ourselves to not let the bad things repeat and to act on it as an improvement point.
It is imperative to look back and review whether the goals we set have been met or if we are still repeating the same mistakes again and again. When teams do a retrospective only once or twice and never go back to review it, only performing the meeting like another chore or task, they lose out on the benefit of perspective.
3. Not involving the entire team
Retrospective meetings are meant to address all types of problems across all areas of the project and related processes. But awareness will come only when we involve the entire agile team, not only hand-picked people or managers. Everyone will have their own story and perspective to tell about what happened during the time period and what they experienced.
For example, a developer may say that what did not go well was that they did not have the correct versions of libraries at the common repository, so when they sent the build over, it crashed at the tester’s site. However, that tester may say that what went well was that they received a quick fix by the developer when the build crashed so their testing was not suspended for too long.
If we do not involve everyone from the entire team, we may miss out on their perspectives and stories and fail to get the real, ground-level issues.
4. Forgetting to talk about the positive stuff
The key to a successful retrospective is to begin with positive stuff, which is why the three key questions to ask begin with “What went well?” Forgetting to discuss the good aspects and give out appreciation where it’s due instead of directly jumping to failures or mistakes, can feel like criticism to the team. This may mar their enthusiasm and productivity and make them resistant toward these retrospective meetings, so it is imperative to begin with positivity and give some healthy appreciation for a job well done.
People appreciating each other also helps encourage team members to help when needed and share their knowledge. Here are some good examples of positivity at a retrospective:
- A tester giving the name of the IT personnel who helped set up a test environment on short notice
- A developer appreciating some buddy tests performed by a fellow tester that helped find crucial issues early
- A test manager expressing thanks for the special script created by a couple of testers that helps upload all legacy tests to the new test management system
This practice brings about team harmony and the spirit of oneness, which fosters the true agile culture.
5. Not following up on previous retrospectives
If we perform one retrospective meeting where we discuss all things positive, negative and improvements but then never hear about them or what happened again, then the entire team loses out on any real benefits achieved from that retrospective meeting.
As we do a retrospective, it is important to maintain a checklist of points discussed, both positive and negative. Also keep a note of the improvement points discussed and bring them up in the following meeting to see if we actually worked on and achieved them or not.
For example, if a developer said that what went well this sprint was that the design changes and improvements they did in the previous sprint actually helped reduce their bug fixing and maintenance time on one module in this sprint, this would mean that the “How can we improve?” discussion from the previous sprint retrospective actually materialized and became a positive aspect of the current sprint.
Having the past record shows a graph of our improvement as a team over time and shows how we converted our shortcomings to successes.
Let’s learn from these points and implement our retrospectives in a better way to realize the maximum potential of our agile teams!
Please share your experiences of agile retrospectives, how you implemented the process and what worked for you.
