Knowing when to change can be just as hard as the change itself. It’s fairly obvious that a team of 10 won’t work the same way that a team of 100 or 1,000 people would. Processes, comms, decision making… All these things will be vastly different depending on the size of your team and other factors like competition, market, velocity, etc.
But how do we know that it’s time to evolve?
Marshall Goldsmith has a great book titled “What got you here won’t get you there”, and that phrase captures the dilemma perfectly. When you adopt a set of processes, you must be convinced that these are the right things to do right now. But there will be a time in the future where this way of thinking and working will need to be ditched because its effectiveness will have run out. This happened to companies like Facebook and GitHub that went from letting people push changes quickly to production to being more structured about their releases. As the number of users grew, it became necessary to introduce better design coordination, spec’ing and planning to keep users happy. “Move fast and break things” became “move fast with stable infrastructure”.
I personally saw this happen in Atlassian. I was there for 6 years and the company grew from 450 to more than 2,500 people during that time (including an IPO). Atlassian went through multiple transformations and its unique ability to adapt played a huge role in its success.
The best teams are able to do 2 things:
- They can quickly rally behind a decision and execute with conviction
- They have systems in place to detect when something is not working anymore
So, the question is:
“what’s the easiest way to know when things aren’t working anymore?”
This is where retrospectives come in. They’re often associated with devs, but they can (and should) be extended to any parts of the business. The beauty of retrospectives is that they act as a forcing function to pause and reflect on how things are working. You’ll often find small adjustments to make, and sometimes you’ll realise that you need to change your entire org structure in order to achieve the goals that you set for yourself.
How to run effective retrospectives
A good retrospective should have 4 main activities:
- A scoring of previous goals
- An objective recollection of past events
- A judgement-free set of suggestions for improvements
- A vote and discussion on the things to act on
I highly recommend watching Wyl Villacres’ Retrospectives Masterclass to get a complete overview of the process, and I’ll give a short overview of each activity below.
A scoring of previous goals
You might have a set of OKRs, KPIs, or other goal-setting framework that guided the team effort in the past month or quarter. The first thing that you need to do is to agree on the current state of things.
Keep it simple. The main objective should be to understand if you’re mostly red, green, or yellow. You can refer to our scoring guide for some tips on how to score OKRs.
An objective recollection of past events
This activity is often overlooked by teams, but it’s one of the most valuable as it helps remove recency bias. The idea here is to list all the key events that happened since the last retrospective.
Be careful. This is not about capturing opinions such as “we had a great month”. It’s about listing events that might have impacted your ability to deliver results. For example: holidays, offsite events, the whole team being sick for a week, going to conferences, etc…
This is a helpful exercise to build a shared understanding of the past before we take a look at what the future could be. It’s also a great way to realise that unknown unknowns happen and that you should plan for unexpected events.
A judgement-free set of suggestions for improvements
Next comes the fun part! There are different retrospective techniques to do this (start/stop/continue, 6 thinking hats, mad/sad/glad…), but the idea is to capture everyone’s sentiment about the past month and quarter.
It’s important to keep this phase debate-free as people write their thoughts. This is not an opportunity for you to tell someone that they’re wrong. It’s an opportunity for everyone to share openly as well as get a sense of what others are experiencing.
Are you seeing something that you disagree with? Just keep it for yourself and wait until the next activity to spark a debate.
A vote and discussion on the things to act on
The last activity is about finding what needs to change. You can easily end up with 50–60 suggestions listed on a board following the previous activity. Rather than discussing each item one at a time, the best is to let people vote on what matters the most. Give 5 votes per person, and you should be able to quickly surface the 3–5 top issues to discuss.
From there you can set an action plan to address these problems.
How to run mini-retros with weekly check-ins
Business retrospectives are normally run on a monthly or quarterly basis. But if you’re using a goal-setting framework like OKRs with your team, it’s highly recommended to have a weekly catch up to talk about progress.
You don’t need to go through the full set of activities. The purpose of the weekly check-ins is to have an opportunity to reflect on progress and re-align teams. That is the extent to which it is similar to a regular retrospective.
Running a weekly check-in meeting can be done quickly by answering these 5 questions for each key result:
- How much progress have we done?
- How did we make that progress?
- How confident are we that we’ll reach our goal?
- Are there any blockers?
- Should we do things differently?
This sounds like a lot of work to repeat every week, but 80% of the questions can be automated with a tool like Tability which is designed for that specific purpose.
The more you reduce the time spent on gathering and capturing progress data, the more time you can spend on solving actual problems and turning red goals into green outcomes.
Resources
Here’s a collection of resources to help:
Originally published at https://www.tability.io.
