Retrospectives have become a necessity in the world of software development. With things changing so rapidly each day, retrospectives are one of the few means to discover and identify the challenges and highlight the great achievements of a team. The way we need continuous feedback loop for our software products to get better each day, similarly, to create great teams, retrospective play a key role.

Retrospectives or ‘Retros’ as we call it have become a platform for teams to come up together and critically appreciate and review their own work. Many times, the intent of retrospectives is largely misunderstood, it should never be made a platform to point out mistakes of individuals or teams. Also, it should never be a means to compare individuals or teams. That will not only negatively impact the team’s morale and performance, it will greatly influence the individuals within the team.

Tip: Think very well about the participants of a retrospective. For instance, if the team isn’t matured enough they might not be comfortable bringing in points related to requirements in front of the PO or related to processes in front of the release manager. Ideally, there shouldn’t be any qualms in any individual in talking about any aspect but it might take some time for the team to reach that level of maturity.

Most of the times retros are considered as a waste of time or ineffective by team members. We might even notice that during retrospectives individuals are not actively participating or are not bringing up the real concerns that we might see during sprint executions.
 
It is imperative to understand that retrospectives should be focused on the following key aspects- 

• Processes
• Product
• Environment

These form the bases of identifying the key challenges and opportunities within the team during a retrospective. If any item that eventually doesn’t impact any of the above can be set low on the priority for the team to work upon.

A concern may not necessarily be directly related to the above three but if we perform ‘5 Why Analysis’ of the problem is, we may end up drilling down to the real area of impact and understand the real problem. There is a big difference between actual and perceived problem. The Scrum Master here plays a key role in facilitating the discussion which leads to identifying the actual problem.

For instance, a team member brings out that, “Retrospectives are a waste of time, we spend a lot of time writing retro items. I can work on my sprint deliverables and be more efficient.” After performing a ‘5 Why Analysis’ on this statement we can probably uncover the actual problem. An individual might feel likewise if, ‘the team is overloaded and feels retros take away considerable work time’, or ‘the output of a retro is never worked upon, we never track the action items, hence it adds no value’, or a combination of both. A probable solution for this could be an efficient capacity planning in the first case or through follow-up and active tracking of each action item during the subsequent sprints.

This is a very innovative technique and is more effective than the recurring retrospectives, in terms of time and covering more ground. Instead of sitting together once at the end of the sprint, the team keeps putting down retro points as they encounter them or experience them during the sprint cycles.
 
These retro items can be either put on a board or dropped into a box as the team may agree to. Now, discussions of the retro item can also be done at regular intervals, or as soon as a specific number of items are identified or even in an ad-hoc manner based on the team’s availability.
 
With continuous retrospectives, we ensure that nobody spends time thinking and dwelling on the past to write the retro items, everyone can put their thoughts in real time and ensure that most of the crucial items are captured as and when they occur.
 
Tip: For new teams, it is very important to first perform retrospectives together, that will help individuals understand the thought process and help team define common goals towards being a better team and making better products.
 
There is no one single best way for retrospectives, but until we keep in mind the intent and desired outcomes of it, any methodology or technique can help us achieve them. Software development today is not just about making world-class software products but is also about making great teams and individuals, and retrospectives are one great tool for us to achieve that.