Taking retrospectives to the rest of the business

The Product Development team at Driftrock has been using retrospectives for just over a year and it’s served us really well. In that time we’ve made loads of improvements and changes to how we work. Those changes range from small tweaks to our process to large uncertain ideas which we trial for a limited period. Our process for a retrospective is fairly typical (in my experience); we do them fortnightly and we rotate the facilitator role who runs the session how they see fit. Importantly, we try our best to ensure we get a few well-understood actions (think 1-4) with clear owners and an expectation that those will be completed or at least moved in some meaningful way by the next retrospective.

What was unexpected here was that the rest of the organisation outside of software development started to show an increasing interest in understanding how retrospectives might help them. To the extent where we now run regular retrospectives with our Growth team, which is a combination of Sales, Account Managers and Performance Marketers. We’ve also had a whole company retrospective, specifically on performance reviews and how we can improve them.

The timeline

Back when I first joined Driftrock, like any new person on any team, I had a few ideas about how we could do things differently but there was no way of proposing and discussing it with the team. The only real option was escalating an idea to our manager and seeking by-in from above, which on a small team of experienced engineers with lots of ideas seemed a little unnecessary.

Enter the retrospective. We started simple, we would try a single retrospective and go from there. As the facilitator I tried to educate as much as possible as we went through our first retrospective. Not looking to overwhelm the rest of the team we kept this simple too, focussing on three main things:

• This is not about assigning blame. It’s important to create an environment which fosters psychological safety and blame destroys that. Things go wrong, we know this, so let’s talk openly about how we can improve as a team and avoid those same mistakes.
• This is not another meeting where we have a nice chat and nothing changes. Actions are a vitally important outcome of our discussion, as is completing them.
• We went back to basics and structured the session around the four key questions.

This went well enough and from there we agreed to commit to regular retrospectives. That was easier said than done, it still needed at least one person to ensure the next retrospective happened, follow up action owners and continue that education process. Over time we got into a good bi-weekly retrospective rhythm, we started tracking our actions and once the team started to see the value, the practice begun holding it’s own.

More retrospectives passed and the team grew with every small improvement, as did interest from outside the team. This led to a brief presentation to the whole company on retrospectives and how we had been using them. What followed was a slight shift in my role which allowed me to focus some time on helping the Growth team get started with retrospectives.

What have I learnt

Running retrospectives for teams who aren’t building software was a new experience for me. Perhaps the clearest observation was that the Growth team who despite having cross over between roles are fairly independent in their work. Therefore it’s much harder to find common ground when reflecting on a specific time-frame. They are much more likely to act on a number of tasks independently in comparison to the individuals on a development team, who are generally working towards the same outcomes, possibly on the same problem and whose roles are very similar. Instead then, we found there was far more value to focus on a theme. For example, we’ve previously had retrospectives focussed on account management and another on roles and responsibilities.

As someone from outside the team you are more limited with how much you can realistically do. It’s much harder to organise anything like this without having someone on the team who buys into it and shares some of the responsibility. Beyond this the team needs to want to improve, needs to see the value early but also needs to find their own way.

Looking further back on the whole journey, even the seemingly simple part of starting with retrospectives on a development team, a few other lessons stand out for me:

• Facilitation - Trying to be the example of an impartial facilitator on your own team is not an easy role to play. This is why we prefer the facilitator to be someone from outside the team. This has the added benefit of improving communication and knowledge across teams, whilst also providing an external check if the conversation is getting too detailed.
• Amplify the good - It’s so, so important that everyone sees the impact of a completed action or an important conversation. Review actions at the beginning of every retrospective, talk about them in standups, make them visible and amplify the best examples.
• There will be doubters - Naturally people will doubt the value, that’s understandable and it’s ok. That criticism is a useful tool for improvement.
• Be persistent - If you believe in it, keep doing it. But be mindful of others, recognise and adapt based on how the team are feeling.
• Be an example - When participating in these sessions, set the marker. Be present and be fully engaged.

What went well

For the Growth team, they’ve felt that this bi-weekly session provides the space away from the day-to-day panics and stresses of campaign and client management. In the session they are afforded the time to spot trends across all the different types of work going on. They can then adjust accordingly and see how it went in the next session.

For me, I’ve been reminded that the retrospective can be a powerful tool for fostering autonomy. When it’s going well it’s an excellent forum for individuals to voice concerns, suggest changes and see those through.

More generally, the retrospective has helped surface an underlying aspect of Driftrock’s culture which was always there but rarely mentioned. As we’ve recently been working on our core company values (watch this space), it’s become clear that part of the fabric of this organisation, is that willingness to learn and try to improve, which this practice really embodies.

If you have feedback, questions or you’ve done something similar then please feel free to get in touch @dan_badge.

Some helpful links:
Retrospective Wiki - lots of practical ideas for facilitation
Retromat - Mix and match different sessions
Agile Retrospectives - Making Good Teams Great
50 Quick Ideas To Improve Your Retrospective

‍