Introduction
This is the second article in a series offering pointers on how to make the most out of a distributed team. The series is based on experience with growing internal teams with additional near shored developers rather than building a completely external team.
The one thing that will make or break your project is how well your team operates as a team but making distributed teams work well is hard work. This article will briefly explain some practises and tools to ensure that your team is one team, not two teams that share a backlog. You will need to invest resources into communication channels and a shared set of rules on etiquette to get the most of a distributed team.
Faces
People (including developers) want to belong to a group. While a few developers definitely fall into the the antisocial sat-in-a-corner-ignoring-the-world stereotype (and many will relapse into this when working on a fun feature), the majority of developers thankfully no longer do. But creating a that close bond when your teammates are not next to you and just a set of blue characters and a funny avatar on Skype is not easy. As such to aid the team to bond they need to see each other. A lot. I’m not suggesting that you mandate that online avatars are photos. Teams should bond in ways fun, imaginative ways as well.
When a new member joins have them visit the other team. There really is no better way to bond as team than being co-located and working together. If you can also try to allow team members to say goodbye in person when they leave the company so the team can mourn the loss of a close friend together.
By having the near shored members of the team visit during their first few weeks in the team will aid in bonding, and also give the local team a chance to instil the values, ideas and practices that they hold dear onto the new members of the team.
Saying hello is not a one time deal, nor should it only ever happen during a “crises”. It is also not a one-way-street. The local members of the team should be invited to travel to the near shored members and they should take this offer up regularly.
The daily standup is vital for the health of any team greater the two people. With a distributed team it is very tempting to just do it over a text chat. However the stand up within a distributed team is also the opportunity to see “the weird pixelated squirrel” as an actual person.
So make the stand up a real stand up, where everyone in both locations stand up together and synchronize. The ideal for this is to have video conferencing hardware/software open and easily available where the team previously held standups. Don’t force the team to trundle off to the Video Conferencing room every morning. Especially if that room is used by other teams as well. Having to go too far is a sure fire way to kill the standup. A simple, inexpensive option here is to make your build monitors multi purpose. You likely already have them close to where the team would be stood up, and if you have a multiple screens, one can run the ticket system and the other a video feed of the remote team during stand up. Make sure you make switching to and from video conference mode bullet proof and quick. Don’t kill your standup with “set up time”.
Some meetings (like the retro, sprint planning and team catch ups) must involve the full team. Rather than having a small number of rooms with very fancy video conferencing solutions running full video conferencing solutions, I’d recommend making sure every meeting room has a good webcam and an agreed on video conferencing and desktop sharing solution. Never put the team into a position where they need to fight for a room or worse - use a Skype on a mobile phone.
Have a directory of real names to real faces, online avatar and online handles. While the team should see each other frequently (ideally daily during standup), members of other teams will not and need a quick and easy way to match a name or handle to a real person they can connect with.
When a new member joins have them visit the other team. There really is no better way to bond as team than being co-located and working together. If you can also try to allow team members to say goodbye in person when they leave the company so the team can mourn the loss of a close friend together.
By having the near shored members of the team visit during their first few weeks in the team will aid in bonding, and also give the local team a chance to instil the values, ideas and practices that they hold dear onto the new members of the team.
Saying hello is not a one time deal, nor should it only ever happen during a “crises”. It is also not a one-way-street. The local members of the team should be invited to travel to the near shored members and they should take this offer up regularly.
The daily standup is vital for the health of any team greater the two people. With a distributed team it is very tempting to just do it over a text chat. However the stand up within a distributed team is also the opportunity to see “the weird pixelated squirrel” as an actual person.
So make the stand up a real stand up, where everyone in both locations stand up together and synchronize. The ideal for this is to have video conferencing hardware/software open and easily available where the team previously held standups. Don’t force the team to trundle off to the Video Conferencing room every morning. Especially if that room is used by other teams as well. Having to go too far is a sure fire way to kill the standup. A simple, inexpensive option here is to make your build monitors multi purpose. You likely already have them close to where the team would be stood up, and if you have a multiple screens, one can run the ticket system and the other a video feed of the remote team during stand up. Make sure you make switching to and from video conference mode bullet proof and quick. Don’t kill your standup with “set up time”.
Some meetings (like the retro, sprint planning and team catch ups) must involve the full team. Rather than having a small number of rooms with very fancy video conferencing solutions running full video conferencing solutions, I’d recommend making sure every meeting room has a good webcam and an agreed on video conferencing and desktop sharing solution. Never put the team into a position where they need to fight for a room or worse - use a Skype on a mobile phone.
Have a directory of real names to real faces, online avatar and online handles. While the team should see each other frequently (ideally daily during standup), members of other teams will not and need a quick and easy way to match a name or handle to a real person they can connect with.
The desktop
In a co-located team utilizing your desk as 2-3 person meeting place is simple. However with a team where not everyone is in the same room then you need to add technology to allow this. This means selecting a good screen sharing and voice chat (video chat is not as important for this).
It is vital to select a tool that the whole team (including devops and the Product Owners) are happy with. Skype, TeamViewer and Google Hangouts all support these features reasonable well, however bad devop support will kill it before it starts.
You also need to be able to quickly talk to the whole team, this means a chat program. Ideally one that will allow new users to read the chat history and ties into existing tools (CI, virtual board, etc). Slack is a great solution to this, but not the only one.
Finally keep the number of applications/accounts required down to a reasonable number. Using the best tool for the job may, when looked at holistically may mean the second best for this job, but best overall. Every communications application you add to your stack means more setup when you grow and shrink the team.
Breaking Barriers
During the first few retrospectives make a point of mentioning communication and ensure that whatever barrier is found in one retrospective is fixed within the next month. Don’t let let communication issues drag on.
Replication
If a physical item (such as a build monitor; or “Monday Doughnuts”) is used by location, try to make sure that it is replicated at the other. You don’t want to create a “favoured” team and kill moral. Likewise try to evenly distribute “seniority” over the two locations (even in a flat team structure you will have unofficially senior developers), without doing so you risk unintentionally turning the team with the lower seniority into code monkeys to throw work at.
Etiquette
- This smaller sized location gets to talk first.
- Internet audio chat is laggy, so let people finish.
- Don’t get upset when a member of the team in the other location talks over you. It is unlikely they mean to do so.
- One person from each location goes to a meeting room 5 minutes before the meeting starts and makes sure the video conferencing software works.
- Always invite members of the other location into quick huddles on design features.
- When an important decision is made broadcast it on the chat solution.
Please let me know if I've missed anything when it comes to building a single distributed team that works as a single team in the comments below.
This is part two of my series of posts on distributed teams. You can find part one here on Pulse and the complete series posted so far over on my personal blog.
No comments:
Post a Comment