This post is written for a product and engineering audience. If you're interested in building tech products this is the article for you.
Retrospectives
A lot of companies use this word to mean the practice of carrying out some kind of project review. In my experience as an engineer, for some teams it’s been used as an excuse to moan and throw blame around, and they are rarely carried out if everything in the project went well.
When something goes wrong, the first thing I’ve seen stakeholders jump to is the sudden need for a retrospective. Then there’s always a defensive, tense feeling around the room - a focus on finding out “who” and not “where” was the problem.
The structure of a retrospective and the timing of when one is held, differs depending on the company, your team or which project management framework you’re following (if any at all).
If, after this reflection, the next project or cycle goes a similar way, it can leave stakeholders requesting more estimates, engineers & product not wanting to commit to anything, and a lot of people questioning what the purpose of the retrospective was.
When the next retrospective comes around people are hesitant -- and even in blameless environments, blame can be thrown around if this point is reached.
When “failed projects” become a recurring pattern, those involved become divided and can’t reach a consensus on what the best path forward is. Each retrospective meeting provides little value and leaves everyone feeling frustrated - “what a waste of time”.
Does any of the above sound familiar?
How we run Retrospectives differently!
We recently finished our third cycle (more on this in a future blog post - but for now consider it a longer, more deeply planned ‘iteration’), and every time we finish a cycle, we do a retrospective. This time round we all particularly felt the value of what was reflected on and the actions we took forward. So, let’s look at how we effectively carry out retrospectives at TEAMS.gg.
Our process has evolved from the retrospectives I’ve run in different teams over the past few years. Straight after joining TEAMS.gg, I put that structure into practice here, too. It’s ever evolving - continuous improvement! - so when you read this we may be doing something slightly or entirely different.
What is the point of a retrospective? Let’s look at one of the most popular process frameworks, Scrum. Scrum.org states that the purpose of a retrospective is “to plan ways to increase quality and effectiveness.” And the team discusses:
- What went well in the Sprint
- What could be improved
- What will we commit to improve in the next Sprint
I feel that the way the topics are outlined by Scrum for discussion are too vague for an efficient retrospective. They give direction to the discussion that allows too much focus on the bad - and favours opinions rather than fact.
Unless we are brutally honest with the facts history will only repeat itself.
We focus our cycle reviews at TEAMS.gg around three pillars:
- Celebrate Success
- Reflect on Change
- Iterate and Improve
You might be reading the above and thinking “You’ve just reworded what’s in the scrum description”, and while I would agree on a simplistic, surface level, semantics, intention and implementation - how you actually facilitate each pillar's discussion - are important.
Celebrate Success
A lot of retrospectives I’ve been a participant in have started with “what went well” - In my experience this has always been posed ambiguously. Do we focus on the process? The project? The people?
It’s important to take time to celebrate what you accomplished within the cycle (for us ~6 weeks). We look at what goals we had and how the data or product now reflects what we set out to achieve
“Released the discord bot!”, “Getting a service running on AWS!” and “Lee coming on board!” are all examples of successes we celebrated in our last review.
Whatever time frame you have between retros, you’ll always have accomplished something!
Any success, no matter how small, is worth voicing. Be proud of your team and the cool stuff that's come out of the past few weeks.
Reflect on Change
In a retrospective, this is where most of the focus goes, and it’s where I’ve experienced a wide range of quality in how this has been presented.
Some examples of topics I’ve experienced when the focus is overwhelmingly on “what could be improved?”:
- Who didn’t work hard enough
- What expectations were miscommunicated
- Why UI didn’t hand over designs on time
- Why didn’t you communicate blockages
- Complaints for the sake of moaning
The above examples don’t actually help improve your team’s process. All of the questions likely have some answer -- but when presented in this way they won’t help you find any root causes, and therefore won't help you find solutions based in fact.
Rather than ask the broad question of “what could be improved” our cycle review process is broken down with a little more structure to help us investigate the root causes of discomfort, which gives more insight into what actually happened
What does this breakdown look like?
First, we review what we set out to make, what we actually made and how this changed over the cycle. There is always change in a project and it’s important not to discuss the why - not yet anyway - and just review the facts of how things changed. We call this step Project Overview.
What does this look like?
During planning we discovered we wanted to track which game a user was currently using via google analytics, what we actually implemented was tracking some session data and event data.
So how did this change? -- we increased the amount of data collected and gained knowledge on using the GA platform.
Then we look at anything unknown that came up and any challenges we encountered we didn’t account for in the initial planning. Uncovered Unknowns are part of life as it’s not always predictable. It’s the start of the investigation into the improvement conclusion of the retrospective. Looking at what occurred and how we can try to limit these unexpected changes in the future planning.
What did we uncover?
With the google analytics change -- it was planned as a quick win, something straightforward! What we uncovered was how complex and powerful the tag manager and analytics platform together can be.
How we worked together, how the process worked for us and what was slowing us down is reflected upon next in the Process Structure review. We highlight, and plan to continue, the parts of the process that have been beneficial in helping us move efficiently. (e.g. We want to keep breaking down Stories! We communicated well and should keep talking! Pairing was awesome, let's add this to the onboarding process!)
Next, we spot any processes that exist just to be processes. Is there anything that we should change or stop doing entirely? Is a process too much of a chore for the sake of it? Was something missing that caused blockers? (e.g. Deploys and merges being blocked by testing as it wasn't clear who was meant to be testing.)
We need to bring these forward into the final stage and formulate a plan of action. The process should be ever evolving!
Finally was there something that caused us to have a Delay on Deliverables. Was someone sick? Did github go down? Did we run out of credits on a service? The aim of this is never to have the points raised here to feel like excuses, but to increase the visibility for everyone in, and even outside, the team of what caused a miss on a high integrity commitment and if there’s anything we can do about minimising these in the future.
In the broken down structure we don’t look at answering - “what can be improved” - process evolution is organic and only when we reflect on what we have learnt can we see the solutions to the problems.
As engineers we sometimes jump to conclusions quickly (I’ve certainly been guilty of this) but taking a step back, seeing where the problems are and building a solution can sometimes help. Especially as we’re working so hard as a team, within the review process, to understand the improvements we can make. The output of the team is always greater than the output of an individual.
Iterate and Improve
Now's the time - with all of the information and discussion we've already had - to start thinking about changes we can make. Changing too much too quickly with any process never seems to work, when it does I’ve always found processes regress and old habits die hard. The main difference between other frameworks such as scrum and this process is the depth of preparation and investigation into the facts; we're discussing potential improvements with a morning's worth of deep thought behind us, not 15 minutes of casual chat.
Once all of the actions have been identified and outlined then we group them, we look at the priority and impact of them and decide together on carrying 2-3 action points into the next cycle
We also assign an owner.
It's important that every action has an owner, or it will be very easy to ignore. We make sure that we agree who has the responsibility of making sure each action is followed, and we check back at the next cycle review to see if they were followed and how effective we think our actions were.
My Final Thoughts
I hope you drew a little bit of inspiration from the structure and success we’ve had at TEAMS.gg by running our cycle reviews in this manner. This discovery and evolution of a structure that works for you and your team is often lost. Each team is different, so you may need to help forge your own retrospective path.
It’s scary to deviate from the forged path but it can yield great results with the right attitude. We’ll continue to evolve as time goes by and in a year or two I might update you on how (and why) things have changed.
At TEAMS.gg we value the importance of always improving and evolving, and part of improving is being able to look back and see how far we’ve come.
It’s important to see not just why things changed but also how. It helps us understand the reasons for change and allows us to apply this experience driving forward.
While sometimes this can be difficult because a process or project may have gone way off the rails, the first step to being better is reflection.
Here’s a picture from the most recent cycle review at teams - retrospectives are part of a collaborative effort to improve and want to be better. Most people, especially developers like myself, are always looking to be a little better. It's important to take the time to do this, half a day or a day, and if you can have fun doing it with the rest of your team then it’s invaluable and creates a great environment to be a part of.
