One of our teams “suddenly” spread over four locations, including onboarding of two external developers. Before, it was a two location team, that met regularly for the sprint change. In the beginning, one of our developers who was already working remotely for a longer time, gave me the following advice: never try to make things work the way they had been working for a co-located team - figure out alternative ways instead. In that very moment, I felt overwhelmed by this new situation. Remote collaboration felt like a huge constraint: you can’t do group work or ice breakers in which the team has to move around. You can’t even go for lunch with your team or meet in the kitchen for a casual chat.
Question any of the existing practices as to whether they are suitable for remote work
The advice I received resonated with me and I started to see this as a challenge and looked for new ways of cooperation. The first thing I wanted to change was the retrospective. Before, we had each team sitting in a conference room in their location and connected remotely via Hangouts, or the team members from our location within Germany traveled to our Hamburg office. However, now I had to deal with 3-4 conference rooms and/or remote team members at once. It seemed impossible to discuss in the way we did before and to summarize results on a Google document. I had the impression that remote members couldn’t equally participate in ongoing important discussions in the conference room where the majority of the team was present.
A new tool to the rescue
After researching some remote retrospective tools, we decided to use Retrium. It was the most convenient tool with a great UX, a smooth support of the moderation flow, and a variety of templates including nice team radar options. When introducing Retrium, I also asked the team (even when available at the same location) to sit in front of their laptop with headsets on. This way, each team member participated individually and equally in the video call. Sitting in a conference room was no longer an option. Even though it felt really awkward to sit in a room together while meeting in a video call, this was the most effective change to our discussion culture.
Suddenly, everyone was on an equal basis and the opportunities for participation were equally distributed. We could see all of the team members individually, could better get their mood by reading their face expressions and most importantly, I could see when someone unmuted, because they wanted to say something and I was able react to that. In the conference room setting, it was difficult to impossible for me to get those small signals. At the same time, the team brought up the idea of a mini retrospective at the end of every meeting. It took just five minutes and provided really valuable input for me. The team members gave feedback on whether they liked or disliked the new online tools we used, whether they wanted more or less strict moderation, and especially also gave feedback on how the sound quality was.
Improve the sound quality
Everyone who works with distributed teams knows about sound quality issues and I can already hear your sighs. We had all the issues from bad microphone quality (so you could barely hear what your colleagues were saying) to Google Hangouts automatically leveling the sound of your microphones. This was and still is my least favorite part about working in a distributed team, but the time spent was definitely worth it. We kept looking for solutions until we had fixed all technical issues. Annoying, but it worked. I had even set up a meeting with the team’s PO, who is working in a different location than I am, just to try out different devices for 45 minutes. We also tried things that might affect the sound quality (e.g. a laptop between you and the microphone) to make the teams aware of what to look for. It definitely helped to be in the remote position from time to time to experience the limiting factors yourself. Another option was to record your meeting (e.g. the daily standup) to become aware of sound quality issues and common patterns.
“Remote first” as a principle
Early in our learning path towards a better remote collaboration, one of our developers recommended a podcast with Bryan Helming, Co-Founder of Zapier, a company that works exclusively remotely. In this podcast, Bryan said, one of the company’s values they committed to was “Remote first”. Like I said in the beginning, examine every process on how you could make a physical process work for a distributed team. I don’t want to bore you with the details, but besides banning all posters or physical processes we had in the team office, we also emphasized the already existing culture of using the team chat for all work related discussions and documenting all decisions in our Confluence space. It also helped to consciously change the habit of just asking the closest colleague of the team to just picking someone from another location to ask for an advice or their opinion on a certain topic.
Besides using Retrium for the retrospective, we also looked for a tool to make estimation more smoothly. We chose planITpoker, because it easily allows everyone to estimate and also gives a nice visual overview of the outcome. Retrium and planITpoker worked so well for us, that we sometimes also use them for co-located teams.
On a good way
Overall, distributed collaboration, that felt like a huge limiting constraint in the beginning, became a big chance to learn to adapt and push my ability to collaborate with the team further. It’s not that we already made it, there are still a lot of things to learn and improve for us. But I had the impression, that by learning to foster collaboration and trust in a distributed team, I also learned a lot on how to do this for co-located teams more effectively.
If you want to go further, here is a list of some of the tools and resources we found useful:
- Johanna Rothman, Mark Kilby: From chaos to successful distributed teams
- Podcast with Bryan Helmig, Co-Founder of Zapier
- Future of Work Podcast with Wade Foster, CEO of Zapir