Two Painful Problems with Retrospectives

Introduction

Pick up any book on how agile works and it will mention the importance of running a retrospective and how to run one. In reality, retrospectives are one of the first ceremonies that get dropped or it gets rushed through because the team is too busy. One reason that retrospectives tend to get dropped or rushed is that they are painful. Not painful in that there are lots to talk about and unpack. But painful in that nothing happens. People talk and gripe, some actions may be identified and then…nothing. This article identifies two major problems with retrospectives and the best way to eliminate them.

Problem One — “Why are we doing this again?”

It’s a struggle to get people to attend and when they do, getting people’s buy-in is tough. They don’t take part or drown out other voices. And those drowned voices sink into their chairs, waiting for the retrospective to finish.

The problem here is not of engagement but the retrospective is unfocused. The group need something to focus on a goal to keep them anchored. They also need a working agreement on what is proper behaviour and what isn’t.

In their book “Agile Retrospectives: Making Good Teams Great”, Derby and Larsen break down retrospectives into five sections:

1. Set the stage
2. Gather data
3. Generate insights
4. Decide what to do
5. Close the retrospective

Setting the Stage

Setting the stage is where you get engagement and buy-in from the group. A key tool that they advocate is the working agreement. The working agreement is a social contract that identifies acceptable behaviour and interactions. If the team has one, bring it into the retrospective and change it if required for the session. If the team doesn’t have one spend some time creating one. This helps to build a safe environment for the attendees to be open, honest and respectful.

“Ask your team to monitor their working agreements during the retrospective. When your team takes responsibility for their interactions, you can focus on facilitating.”

Another tool to help the team focus is having a goal for the retrospective because it gives a reason why team members are giving up their time. It doesn’t preempt the outcomes and actions. It helps to anchor the team and minimizes them going off-topic.

Before the retrospective, spend some time reviewing the team’s performance, the history, morale and state of the project. Look at the information available like burn down charts or defect statistics. Observe the team and see the dynamics at play and talk to the team members. This will provide you with some idea of what the goal of the retrospective should be.

At the beginning of the retrospective talk through the goal of the retrospective to get buy-in from the group. There is a risk that the group disagrees and you need to change the goal.

Don’t choose a goal so narrow that it blinds or restricts the team. Nor a goal so broad that the team can’t find any lessons or actions. Choose a goal broad enough that it leaves room for the team to think creatively and find insights.

Problem Two — “Nothing changes”

At the end of the retrospective, there will be a whole bunch of ideas, suggestions, insights that the team has come up with. What usually happens is that actions are identified. If they’re lucky, those actions might be allocated to someone. If not, those actions sit in the backlog. And when the team gets busy, the actions get pushed further down the backlog.

You and the team can do a few things to make sure these actions do not disappear into the ether.

1. Make sure the team agrees on the actions to work on. If they have to buy in then they are more inclined to make sure it gets done.
2. Get it on the backlog and treat it like any other scope item. Break down the item into tasks, allocate points, take it into a sprint and make it part of the sprint review.
3. Include some time to the team for continuous improvement. This is always challenging. The team need time to improve. They can’t be spending all their time building features. Set some time during the sprint for improvement.
4. Ownership. In Agile, tasks do not get allocated to individuals. They get pulled by the team when it’s ready. Sometimes this doesn’t work. Retrospective actions can be hard. In this situation, getting someone to own the task may help to progress it. If it’s hard, then the Scrum Master or Product Owner may have to own it to get escalation.

Now What?

There are myriad other challenges. Improving how you deal with these two problems will go a long way in improving your team’s retrospective. You and the team will need to continue to work on these at each retrospective. Practice makes perfect. Try one of these actions at your next retrospective. Then work on the next one at the following retrospective.

Actions

1. Set a goal for the retrospective
2. Get a working agreement for the retrospective
3. Get agreement from the team on the actions to take into a sprint
4. Put the actions in the backlog and treat it like any other backlog item
5. Allocate time for continuous improvement during the sprint to work on the action
6. Identify the owner for the action if need be.