How retrospectives can go bad

Anyone who's experienced Scrum understands the relevance of retrospectives.

The importance of this scrum ceremony can not be overemphasized. Without retrospectives, we do not get an opportunity to pause and look back - something that we refer to as "Inspect and Adapt". We "Inspect and Adapt" two things - the product that we develop and the process we use to develop it. We "Inspect and Adapt" the product in the ceremony called "Demo" or "Sprint Review", while we "Inspect and Adapt" the process in retrospectives.

However, if we aren't careful enough, this essential ceremony can easily loose its value and be reduced to just a chit-chat meet or even worse a whining meeting - "... this is bad... that is bad ... everything is bad.." People get out of this meeting completely demotivated and the result is more hits on naukri.com (or dice.com, or monster.com if you will...). We obviously don't intend this. To avoid such a dangerous outcome of a scrum retrospective, we need to go three steps further:-

Step I: Ensure Participation: During the various classes, workshops and events that I speak at, I always observe a sub-set of people always speaking up - answering questions, questioning answers, seeking clarity and so on... While there are others who don't speak up. Only when it comes to hands-on activities, they demonstrate their prowess. That's human nature - some of us are more verbose than others. This, however, doesn't mean that people who are not speaking up do not have a brilliant idea of improvement that can enrich the retrospective. To be able to give a fair chance to all, I find it very effective to standardize the syntax (Good and Bad points, or start-stop-continue points) and go in a round robin basis (usually passing-on a visual aid like a board marker to indicate who speaks up next) such that everyone gets a clear opportunity to speak up. 

Some people might report - "All my points are already covered, nothing more to add" - that's pretty ok! - we do not want to force people to innovate, we just wanna give everyone a fair platform. 

Step II: Identify "action items":

If we follow the first step above, more often than not, we'll end up with a rather big list of improvement items. If we leave it there, the same improvement points will bubble up in subsequent retrospectives, leading to wastage of time and effort. Hence someone needs to pen down all the points of improvements being made by the team members. Once everyone has shared their points, this consolidated list needs to be put up for the entire team to look at. 

This is then followed by something called as Dot Voting, whereby everyone gets 3 votes. One at a time, the team members cast their vote as to which of the improvement points do they feel are the most important points to focus on and improve in the next sprint. Once we have all the votes in, we take up the highest voted points to act upon.

These highest voted points - the ones which the team feels are THE most important points of improvement are called "action items". Step II is - Identify your action items.

Step III: Assign "action items" to "action owners": Once we have the action items identified, it becomes everyone's responsibility to act on them. However, from our daily life experiences, we know that "Everyone's responsibility is No one's responsibility". Hence its time for team members / scrum master to volunteer to take up action items and be the "action owner" of that action item.

Even if an action item is applicable for the entire team, for instance, "The daily standups never happen on time and they also stretch too long" is something for everyone to act upon - even for such action items, its usually good to have an action owner who ensures that in the upcoming sprint, the team recalls every single day that THEY (the team) voted this as a high priority point of improvement and they better focus on the same.

Always start a retrospective by looking at the the action items of the last retro and asking the action owners about the status of the same.

When a team follows the steps above, they invariably always end up with a much more effective retrospective. By "effective", I mean that the action items are not repeated over retrospectives and the team's capability (productivity / capacity to take up and complete work) increases over a period of time.

Notice that the velocity may sometimes fall in a short period. However, a long-term effect of well-executed retrospectives is an upward slope of velocity.