Retrospectives for distributed teams
The retrospective is the process that I use to iterate on how we work together as a team, to continuously improve ourselves.
When I first started doing this we would write up on a whiteboard three faces: smiley face, sad face and confused face.
Everyone would then get a different coloured whiteboard marker to write up things that had happened in the previous week that they were happy about, sad about or confused about.
Usually we time-box this process to 5 minutes and at the end we go around one by one to discuss the issues for 2 minutes each. At the end of the 2 minutes you can extend the discussion for another 2 minutes or create an action item and close the issue.
From start to finish it takes from 30 to 60 minutes.
Creating a way to identify problems in your team, and to fix them, is one of the most valuable ways to create a productive business.
Every team is going to have great parts of its culture and processes and terrible parts. It’s how you work through these that makes the difference between rising up and flaming out.
For distributed teams retrospectives can be harder to do. Different people working in different locations, sometimes on different timezones and with varying degrees of video latency all create complications in the process.
The quieter team members can be overlooked, the loudest voices can dominate the conversation, the important issues can get drowned out.
These are the six rules I live by in running retrospectives for distributed teams.
1. The location with the most people wears the majority of the pain.
At GoDaddy our Sunnyvale office generally has the most people in it. This gives the people in that location a huge advantage. They get to discuss items face to face in the hallways and have lunch together most days.
Because of this huge advantage I don’t think it’s too much to ask Sunnyvale (or whatever dominant location) wear a little pain to make distributed teams work better.
For instance this could mean everyone in Sunnyvale splitting into separate groups or huddles to run the retro to avoid it becoming a single-room conversation.
It could also mean having a single leader speak on behalf of the group rather than a free for all where the cacophony of voices doesn’t easily translate over VOIP.
2. The location with the least people runs the meeting
The fewer people in your location the harder it is to have a voice.
The location with the least number of people should run the meeting to keep things on track. This might even extend to having an individual run the meeting if they’re working solo.
‘Running the meeting’ is deciding on the format, keeping track of time and making sure everyone is being heard.
3. Each group should have a delegate
Every location has a delegate assigned to make sure their group or location is heard.
As each issue is discussed a delegate from each location makes sure everyone at that location has their input, and is able to trigger when an issue is closed as well as taking down any action items.
4. Text should be as highly respected as voice/video
You need to make it easy for people to participate without needing to shout over others.
The most outspoken people shouldn’t be the voice of the group by default, you need to create ways for the quieter and more introverted of your group to have a voice.
Text chat is a simple way to allow everyone to have their say on a topic.
Messages can be posted in the team Slack and should be read out by the delegate as they come in and before the topic is closed out.
Text is also a great way to vote on anything that needs voting on and keeping track of action items.
5. Every meeting should have a redundancy in access.
A terrible internet connection shouldn’t preclude you from participating in a retro.
Some members might be working off their mobile phone or in a location with terrible wifi.
Every meeting should have a voice/video channel where possible (like Google Hangouts), as well as a number which can be dialed in for those whose connections are failing (like Lync).
Having as much of the meeting documented in plain text in real time means that even without voice or video your team can still follow along.
It’s up to the team running that weeks meeting to make sure that these are setup ahead of time and sent out to everyone involved.
6. All topics should be covered.
There is a tendency to close out a retrospective meeting when you hit a certain time limit, or to discount topics that the leader of that meeting might feel unimportant.
If someone thinks a topic is important enough to raise it at a retrospective we owe it to them as a team to make sure it’s addressed.
If you work in a distributed team I’m keen to hear how you manage your retrospectives. Ping me on Twitter at @nedwin.
Related resources:
a) On facilitating distributed team retrospectives (pros and cons of different approaches)
b) Remote retrospective patterns from Adobe’s Agile Camp
c) A wiki setup just for retrospectives in agile including methods, tools & “common ailments & cures”
