3 Reasons Why Retrospectives Suck – Part 1 – Too Narrow Focused

How to get better at getting better

We can deliver digital products faster now than ever before. The increase in computer power and new methodologies like agile delivery practices has been two factors to this in the last 20 or so years. The ability to deliver fast has now become commodity and delivering quality for people is more in focus than ever.

In my own experience as a designer in agile delivery teams I’ve often seen teams focus on speed, often trading off things which might seem a waste of time. For example learning from mistakes or taking time to document knowledge. Ultimately losing out on opportunities to perfect the solution they’re ultimately creating. Without continuously learning from mistakes teams risk keep doing the same mistakes over and over and getting stuck in short-term thinking. When taking the time to slow down and reflect on past mistakes companies can start playing the long game. Slow is smooth, smooth is fast.

Designing a beautiful process is the new black

It might sound a bit counter intuitive to hear from a designer, but I’m a big fan of standardisation of process. Improving on processes and procedures is probably the least sexy subject to bring up over coffee with anyone in my profession – but I’m big on this. If teams can worry less about inventing the wheel every single time, more time can be spend on being creative. More time can be spend on designing products which people love. This is still about being fast, but doing so without trading off on real value. Value with a big V – not volume.

The value of a fine tuned process isn’t new for other industries. The late night Show host Stephen Colbert talks about how important the process is for his team:

“We have an ironclad process and within that there is flexibility. But the first thing you need is to have things to be repeatable like a clock on the show, so you then can take risks. […] 51% of the show is what the viewers see, 49% is the process during the day. […]. If the process is beautiful then you’re way ahead on the show.”

Creating a process and constantly building upon that process is at the heart of software design.

An example of a company that has become the poster child in software of continuously improving processes (except Toyota) is Spotify, through their loved and copied “Spotify model” (internally known as Spotify Engineering Culture) and their embedded mindset of never finished and always better. By using tools like their Squad Health Check Model and their Retro kit they make it easy for their teams to be good at improving. they are constantly improving not only their product used by 217 million listeners but also their internal processes and methods. (Read more here),

Traditional Retrospectives really suck when trying to get better

One of the tools used in the agile delivery process to continuous learning are Retros (short for Retrospective). The Retro is crucial to success of teams but are in my experience not done very well.

There are 3 reasons why and how you can start getting better at getting better.

Reason 1: The focus tend to be too narrow.

The retrospective can be done on different time scales. Most commonly they’re done at the end of a delivery sprint looking back at the last couple of weeks of work to improve for the next one. During a session the team asks themselves what went well and what didn’t go so well. This helps the team identify problems which has come up in that last sprint, which is great.

What this narrow time scale doesn’t do is helping the team seeing the bigger picture. If a team doesn’t even know there are systemic or reoccurring issues, then how would they be able to solve them?

Getting caught up in details is very human – but what humans are also very good at is finding patterns in medium sets of information. If we can set up these retrospectives to become another data point in a larger set of data – the team would be better set up to see where they need to put their energy. That relatively small issue from last retro might in the bigger picture become quite important – since it has occurred multiple times.

Zooming out to see the bigger picture will allow for more useful improvements.

4 tips on how to see the bigger picture

• Build on the collective memory. Instead of talking about new issues every Retro, bring in the existing ones from last one to see if there has been any changes to them – then add new ones. Keep track of them somewhere – a spreadsheet, or a document. Maybe even the wall if that suits the team.
• Have participants write their issues in full sentences. Single word post-its should be banned since it makes it harder to understand the meaning of “release” when the person who wrote it isn’t around to explain.
• Have a specific owner of the “bigger picture”. This person’s job would be to see patterns in the details. It cannot be “the team” since the responsibilities of this role is to capture findings continuously. Of course this can and should rotate between different team members.
• Document all data at every retro and categories them. To see bigger picture sort the issues into themes such as “roles and responsibilities” or “remote access”. This would be the responsibility of the Bigger Picture person.

This is the first part of a two part article series – Next part covers Reason 2; Continuous improvement is not a popularity contest and Reason 3; Solutions is not the solution.