Retrospectives: The Basics

In the previous post we looked at why retrospectives can be valuable to an organization. Essentially, no one knows the full story and each person has their own part to tell. In using a retrospective each person gets the opportunity to tell their story and share their experience with the goal in improving the project. In this post I would like to go over the basic structure of a retrospective, so that the maximum benefit can be obtained.

The Key Questions

Most people have probably been exposed to this part of the retrospective. The idea here is that at regular intervals you take the time so that the team can reflect on how to become more effective. Normally, this involves asking the team members to jot down their points of view on Post-It notes, to the following three key questions:

• What went well?
  In this question you list and acknowledge the good practices that the team are currently doing. This inspires the team to do further experimentation as well as gives positive feedback to the changes that they have made. This process will hopefully "cement" the ideas in place so that they can be carried forward into future iterations.

• What didn't go so well?
  By looking at what didn't work, you can identify the pain points that the team were experiencing. It is important to identify the root cause of the problem to make sure that they correct the problem and not a symptom.

• What puzzles us?
  This question is meant to address any issues that didn't get answered in the previous two questions. It allows the team to ask questions which they wish they had answers for. I must admit, I had never been to a retrospective where this question was asked, but upon further investigation I could see the
  benefit in it. For example, some of the following questions could be asked:

• "Why did I only complete half of my tasks this sprint?"

• "Why are most of the people not attending our demo's?"

• "What caused us to work so many hours overtime?"

Asking these types of questions would hopefully either fill a gap in the teams knowledge or at least cause some investigation into the matter.

The Phases

In order to get the most out of the key questions listed above, it is useful to encase it in a framework who's steps are listed as follows:

1. Set the Stage
   At this starting point, you set the stage by stating the point of a retrospective as well as setting the time frame for the period of review. If you have had previous retrospectives, this is where you would review the results of any actions taken. Lastly, it is also the ideal place to mention the Prime Directive (See below)

2. Gather Data
   The next step is to collect all the facts that stand out in the minds of the team members. This will assist in creating a shared memory between the team, and help them recall pertinent points in the sprint. This information would be either presented as a mind map, or a timeline where all the relevant points are marked on it with sticky notes. Each point should be place on a separate sticky note.

3. Generate Insights
   After gathering the data, the team then explores why certain events happened or how they impacted the team. It is important for the facilitator to ensure that any blame is assigned to any specific individual and that the team only focuses on causes and not solutions, as that is part of the following step. It is at this point where you would ask the key questions listed above.

4. Decide What To Do
   Following on from the previous step, the team now looks at all the causes and tries to identify possible solutions. If the team attempts to tackle to many of them, they risk not completing many of them. Instead, a better option would be to focus on a few viable options. Don't forget to assign any tasks to the relevant team members & follow up to ensure that they get completed.

5. Close Out
   The last step involves the team asking in questions and ensuring they understand what the outcomes of the retrospective were.

The Prime Directive

The Prime Directive is used to set the stage for the retrospective and goes as follows:

Regardless of what we discover, we understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.

When I was first doing my investigation, it was suggested that this be read out at the beginning of every retrospective. Personally, I felt that it was a waste of time and felt more like a ritual, so I investigated the reasons behind this. From my research, many people said that they found that when they skipped the Prime Directive, the quality of the retrospective deteriorated. The reason for this has to do with the Pygmalion Effect, which essentially states that people tend to do better when they treated as they are capable of success.

Team Differences

You may find that some high performing teams feel that regular retrospectives are unnecessary. If this is the case, you may be working with a high performance team, although most teams seem to be dysfunctional.

• High Performing Teams
  These types of teams often understand the strengths & weaknesses the other members and when they are challenged with an issue they confront it head on. They also look at ways in which they can improve the process without the need of a retrospective. You will also observe them mitigating risks before they ever become major issues, essentially running a "continuous retrospective" while working. Like I mentioned above, in my opinion, not many teams operate in this fashion.

• Dysfunctional Teams
  On the other end of the spectrum, we have teams who find it hard to trust each other and avoid committing to any tasks or accountability. In addition, the teams will often ignore any issues that need to be addressed and any conversations usually end up in arguments where people are left unhappy. Any risks that may occur quickly become issues as the team members avoid them and hope that they don't land up with the issue on their plate. From my personal experience, this is what most teams are like.

As you can see, dysfunctional teams are more likely to find retrospectives more beneficial and will require them regularly, whereas the highly performant teams will be the opposite.

Culture

I briefly touched on this in the previous post, but the culture of a company may be the first hurdle to clear. Some companies will be quite hostile in the sense that people are simply to afraid to implement changes for fear of the consequences should they fail. In these environments retrospectives can provide a place where people can voice their opinions. On the other hand, a company may be accommodating and welcome any opportunities to improve the company, even if it means failing and learning in the process.

I hope you found this high level overview of what a retrospective should consist of quite useful. In the upcoming posts we will look into the importance of preparing & facilitating retrospectives.

Until next time...keep learning!