Focused Retrospectives

One of the most powerful tools I’ve found for building strong teams has been running safe, regular, fun, challenging, personal and focussed retrospectives. Retrospectives are about the way the team is interacting and the way the work is being done, rather than the work itself. They are private, internal, and for the benefit of the team. I’ve already talked about making retrospectives safe and explained how regularity, fun and challenge are key, plus how they can be used as a tool for personal improvement. 

Now let's have a look at how focusing on specific aspects of the way the team is working can yield the changes necessary for really high performance. 

How to create focus

If you are having a focused retrospective, everyone on the team should be clear what the focus of the retrospective is, and ideally should have some advanced notice so that they can prepare and also so that they can find other ways to raise issues that they were saving for the retro. At the start of retrospective remind everyone what the focus of the retrospective is and ask them to stay on the topic. 

Not your first retrospective

Firstly, it's worth noting that having really focused retrospectives should be saved until the team have been up and running for some time. A focused retrospective is about getting into the nitty-gritty and not about fixing the low hanging fruit. I'd only use a focused retrospective in the first month or so of a team coming together if there was something very obviously sub-optimal about the behaviour of the team (see the elephant below). For a new team a series of varied and general retrospectives are more appropriate. 

For teams that are doing the basics right, focus allows you to dig into the process in ways that general retros just don't allow. They can unlock an additional level of performance, trust and happiness within a team. 

Address the elephant in the room

Don't be shy about making the focus the thing that no one wants to talk about. 

I had once worked on a project where after 4 iterations we were starting to see a very clear pattern, despite being "dedicated" to the project, it seemed that nearly all of the team were constantly being pulled onto other tasks and we weren't making anything like the process that we should have been making. I highlighted the issue and asked the team to make that the focus of the retro. It was a very revealing conversation, the team were honest and it shone a pretty bright spotlight on the issues they were facing.

In another retro I was facilitating, we'd started fairly general, but there was something missing in the way the technical side of the team and the business side of the team were talking. We started to focus on communication and language. 30 mins later we'd had a significant turning point in the project. Both sides were frequently and freely using language that the other side either didn't fully understand or was down right mysterious to them. It had gone on for a while and no one wanted to raise it. The actions were simple and cheap in terms of time and energy, but transformative in terms of trust, understanding, and team cohesion.  

Roles under the spotlight

In most agile teams there are roles, for example, Scrum master or agile lead, product owner, developer(s), tester(s), and many others. It's relatively easy to make the focus of a retrospective about one of the roles. Importantly the, person or people in that role should feel safe and comfortable to have the retro focus  directly on their role. The focus should provide an opportunity for people to talk about all the good things that a role is currently doing as well as the areas where improvement is possible. The person or people in the role should also be allowed a fair amount of time to talk about their experience and how the rest of the team could better support them. This may be a great opportunity to get some long-standing issues aired.

Sweat the details

Lastly a good focus for a retrospective might be to pick one specific part of the agile process for example:

• the quality of the user stories in the backlog
• the way work is making its way into production
• the way work is added to the backlog
• the relationship between the team and the rest of the organisation

Going deep on a specific area allows the team to really think hard and explore new ideas about a part of the agile process which they'd perhaps not considered before. Over time a number of these focused retrospectives can establish really strong levels of consistency and clear expectations for the team.