Retrospectives are short meetings held by project teams (not necessarily, but more often than not, working under the Agile framework) at the end of each project or process, whether it’s just an iteration or an entire release. The aim of retrospectives (or “retros”) is to discuss the reasons of success and the issues experienced during the project in order to identify what’s working well and what needs to be changed. These meetings help improve processes and optimize the efficiency of a team’s work by defining what was successful in the project, and what improvements could be implemented in future iterations. Simply put, the purpose of retrospectives is to determine what the team needs to:
- Start doing
- Stop doing
- Continue doing.
Although a retrospective is a standard Agile method to drive iterative and incremental process development, and as such, most Agile teams are conducting them after all of their sprints, releases or projects, there is a general feeling of uncertainty regarding these meetings. That is a consequence of the lack of a thorough understanding regarding the purpose and inner workings of retrospectives: without knowing how to conduct them well, retrospectives fail to achieve their goals, and as such, are just a wast of time for the team.
So how does one ensure their retros fulfill their purposes and drive positive change for the team?
The 4 Questions to Ask During a Retrospective
The four basic questions you should ask (and answer) during your retrospectives are:
- What went well?
- What didn’t go so well?
- What have I learned?
- What still puzzles me?
Retrospectives should be collaborative and constructive meetings where team members are cooperating to identify problems and find solutions. Blaming and complaining should be avoided at all costs – once team members start playing the blame game, people will be reluctant to come forward with their own mistakes, and think about how these could be avoided in the future. The purpose of retrospectives is not to exchange complaints and wishes about issues. Stick to the facts, and try to find real solutions for issues rather than just identifying them.
Reviewing progress and improvements made since the previous retrospective is also of key importance: review and reflect on the results to make sure the team understands the value of retrospectives. Once they start seeing how these meetings actually drive positive change, they will be more willing to engage in the discussion and work to solve problems.
Successful Methods and Best Practices
There are several methods and practices to conducting efficient retrospectives, one of the most popular being “silent sessions” at the beginning of each retro. During these short (3-5 minute) periods, team members should try to identify issues individually and in complete silence, and jot them down on post-it notes.
Once each of your team members have shared their notes, consolidate the replies and choose the areas you’ll be focusing on improving. Decide about the course of action needed to improve on these areas. It’s usually a good idea to nominate owners or “champions” (it’s best if they volunteer) of specific improvements – naturally, these responsibles will not be working on implementing solutions alone, but they should be coordinating the work on that specific issue.
Using “action replay” is also a helpful method: after setting up a timeline, have your team members add events (positive, neutral or negative) in the order they have occurred during the project. Visualizing this sequential flow of events helps identify patterns and tackle returning problems.
Set up an improvement plan as a separate project with commitments, tasks and story points similar to any other project. This helps ensure that improvements are treated with the same respect and sense of urgency as any project. Use codeBeamer’s project management and collaboration functions, Wikis and a Kanban board to manage work and track the progress of these improvements.
Common Problems to Avoid
In addition to making sure you ask the right questions and use suitable methods during retros, you should also pay attention to some of the common problems plaguing retrospective meetings in many Agile teams. A lack of focus (often triggered by obligatory participation), choosing major improvements that the team just doesn’t have the time and resources for, and a few loud individuals dominating the conversation (preventing the participation of less confident team members) are all frequent issues that many teams experience. An equally high level of participation among team members should be encouraged.
Another hindrance is focusing on problems that your team just doesn’t have control over – if you can’t change it, it’s best to find a way to work around it, rather than lament on it pointlessly. Make use of your codeBeamer project created for these improvements, and keep track of task story points to estimate the work needed to cover these major improvement tasks.
Retrospectives are in fact valuable for any team, as they help improve and fine-tune processes based on team members’ experiences; therefore, they should be leveraged to their full potential. Take advantage of our helpful tips and best practices to ensure your retrospectives aren’t just treated as a necessary formality, but are actually useful means of developing your team’s internal processes.