When I started at BugHerd nearly a year ago, I was a little surprised to find that a company that seemed to have their act together in so many ways didn’t do regular “retrospectives”. For the last five years, I’ve worked in several places where a weekly or fortnightly retrospective was par for the course.
When the team at BugHerd looked like they could use the help of a regular retrospective, I put my hand up to get one started.
What is an Agile Retrospective?
If you’re unfamiliar with retrospectives (or retros), they’re generally found in companies that practise Agile development.
The idea is that at the end of a sprint, everyone involved gets together and reflects on the past 1-2 weeks considering:
- what you got right
- what went wrong
- and everything in between.
The idea is to be open and candid so that the bad things can be discussed and dealt with instead of being left to fester.
In our case, I was noticing that at lunch the team were often already discussing certain issues, some times with positive outcomes, sometimes not. This was ok except that on occasion I noticed the same conversations coming up over and over. It’s great to talk about it, but as they were only informal chats they weren’t getting any closer to getting resolved.
One particular example was the choice of WordPress for a blog platform. The people writing the content loved it (as did the designers that created it), but it created a terrible technical headache for the dev team who ultimately had to look after it.
Seeing this endless loop of discussion and lack of team communication, I thought it was time to introduce retrospectives. Agile retros are usually just a tool for a team of developers, but given our size, I invited everyone in the company to sit down and have a chat. The process is actually incredibly simple and is a very effective way of raising issues in an environment where one goal is to get them resolved.
Our process for team retrospectives
I start by handing out some post-it notes and pens and asking the team to write down things they’ve found good, bad or puzzling about the previous week or two. Once they’re done they all get stuck up on a whiteboard for all to see. After that, I asked the team to come up and vote for the things they want to talk about. The voting style people use vary a lot, but it’s good to mix it up anyway, so don’t worry too much how you go about it. For us, I let the team cast one vote per item, but they can vote for as many issues as they like.
As I expected, the WordPress issue that had kept coming up over lunch was one of the most voted for topics. So I threw open the conversation to the team and we had a pretty decent chat about it.
At first, everyone had a good vent, including some of the people who were happily using WordPress every day, but then we got settled down into a good discussion. The devs got to understand where the non-devs were coming from (ease of use, SEO tools, autonomy etc), and the non-devs got to understand the technical problems caused by WordPress (source control, deployment, using PHP without any PHP devs etc).
Once everyone had a good understanding of the problem space, we naturally started talking about other options that everyone might be happy with. Rather than arguing continually about the differences of opinion, getting the facts out in the open meant we could put our heads together and come up with a solution. Everybody is happy!
Team retrospectives in action
I’ve run a few more team retrospectives since then, and we’re still trying to find what exactly works for us (including trying it on a Monday morning, which didn’t work out too well as people had forgotten about frustrations from last week). In the end, we’ve ended up running them on a Thursday morning which seems to be working out OK (and if that doesn’t we can just add it as an issue to talk about at the next retrospective).
Like any tool, it’s really important to be aware that retros aren’t without their dangers! If you have a team that isn’t accustomed to open conversation, you may start a debate that can be hard to reign in. If you have a management team that simply won’t act on the outcomes, the same issues will likely appear every week (which can often make matters worse). If you have one or two overly vocal team members, they can tend to drown out the rest of the opinions. These aren’t issues with a retrospective obviously, just things to be aware of before you rush off to try it with your team.
At BugHerd, we’re lucky in that we were already having 1 on 1s with the boss, as well as monthly team meetings, both which provided a good avenue for discussion.
The big difference is that retrospectives are the one time, as a team, that we can all sit down with the singular objective of making the company better and enact and agile project planning session.
Sometimes it hurts. Sometimes it can make people frustrated. But it’s always better to deal with the frustrations than it is to let them simmer under the surface. These things will always come out eventually, and I’ve found it’s much better it happen in a co-operative, non-threatening environment than it is to let explode some time down the track.
