As business goes global, operating across territories and time zones, teams have become scattered by necessity; you may often find yourself in situations where developers are not physically in one location. This can be a challenge when it comes to using development frameworks that emphasise face-to-face communication, team collaboration, and planning. Iāve been working in this kind of environment for a number of years, and in this article I share some of the things Iāve learned about making distributed teams really effective.
Iām currently working with several development teams based not only in different buildings, but also in different cities, countries and continents. To be effective, these teams need a way to work together, have regular progress meetings, be on calls with stakeholders, discuss requirements to launch a product, and so on.
This is already a challenge for multiple teams working in one location - so you need only imagine what youāre faced with when working with distributed teams across as much as an ocean!
This article talks about my experiences with distributed teams, some of the ways Iāve managed to work effectively with distributed teams, and the main challenges that Iāve faced in doing so.
Firstly, what is a distributed team?
A virtual team (also called a geographically dispersed team, distributed team, or remote team) is a group of individuals working across time, space, or organisational boundaries, but that are linked by webs of communication technology. Different kinds of team structures in these cases can include:
- Co-located teams: One team working at the same table, in the same building, but in multiple rooms and/or floors.
- Multi-site teams: One co-located team working at one site, and another co-located team working at another site. For example, a Johannesburg team and a Cape Town team working on the same deliverables.
- Dispersed teams: One team spread out in different locations - either different rooms, buildings, cities, countries or continents - which often happens when development work has been outsourced to lower-cost countries.
With the above teams, there are a few areas in which you can manage the way you work more effectively in order to adapt to a dispersed, or distributed team. The ones I will touch on are:
- Coordinating across time zones
- Simulating coffee corner agreements
- Building rapport
- Collaborating across cultures
Coordinating and communicating across time zones
Time zone differences can add extra complexities to managing a team: How do you coordinate a development team working between Europe and India, which has a time difference of 4.5 hours?
Often, a companyās distributed development teams work on independent parts of a solution. However, at some point, you will need to think about integrating the software, which is when you will need a high degree of communication and coordination between the different teams.
Not having this in place will affect the quality and there will be a much greater chance of integration problems.
Regularly scheduled meetings using an agreed communication tool will help, as will flexible working hours and the ability to work from home. If you can, rotate meeting times so teams in one time zone donāt always bear the burden of adjusting to their colleaguesā working hours. You can, for example, agree to have the daily meetings for the first sprint in the early afternoon and the second sprint meetings late in the afternoon.
Simulating coffee corner agreements
Itās important to understand the power of informal communication - or as I like to call it, "the coffee corner agreementsā.
Hereās an example:
Youāre a product owner and youāve popped to the coffee station to get your java fix. While there, you bump into a developer on Team X. You chat about the weather. He asks you what you meant by the exit criteria for the user stories heās been working on, and what kind of blue the button on the acceptance screen should be. You thought azure blue, might be a good idea, which is part of the company logo. You chat some more and come to a decision right then and there.
This type of informal meeting can often lead to decision making and happens all the time when youāre in the same building. However, members of distributed teams and remote workers donāt have the same opportunities to gather information or hear news informally like this, which means that those opportunities have to be created and encouraged deliberately.
One way to do this is for the product owner and/or scrum master to invest in informal communication streams, and spend as much time as possible with their teams when they do have any kind of interactions - both virtual and physical. Appointing a local product owner who liaises with the central team can also help, and local and face-to-face communication will help the teamsā communication.
Product owners can also describe the acceptance criteria and requirements for each project in as much detail as possible, and record those details in a voice-note or document. This will make sure that the information is captured and accessible to all team members at any time, when they need it.
Building rapport
Patchy communication contributes to yet another problem: When working across different locations, itās easy to get stuck in an āus versus themā mentality - or a āheadquarters versus everyone elseā mindset.
This can result in friction and resentment, which can worsen already deteriorating communication. Itās easier to blame someone else for a problem or an error, especially when itās directed at teams that are in different locations.
However, with a little effort, you can build more robust rapport across teams in different locations, especially if you do this at the beginning of a project. What has worked for me in the past is to spend sufficient time working on a well thought-through communication strategy, and have regular workshops and team events. This has helped engender an open and honest culture, which in turn helps with building trust and stronger team relationships.
Over the years, Iāve learned that there is no such thing as too much communication when working with distributed teams.
As a product owner, plan regular visits to your distributed teams. Every three months or so, I fly the teams in so they can sit together and communicate face-to-face.
Compared with unhappy stakeholders and customers, this cost is one that you cannot afford to leave off the balance sheet. When I plan these visits, I schedule specific time for the team to explain any issues or challenges, and I always bring cookies for a little sweet treat!
Collaborating across cultures
Writing from our headquarters in Cape Town, I can truly say that cultural differences exist even between different locations within South Africa. These differences can become more pronounced when you start traveling across continents. Being āawareā of cultural differences is the first step towards mutual understanding and respect.
Mitigating this issue requires a far longer post on its own, but something I am very intentional about is spending as much time and money as necessary to bring the teams together. I do this by working on establishing trust and understanding on a personal level: What drives each person to go to work? How do people spend their holidays? What are the local public holidays and what are their significance?
For example, many Europeans spend their summer holidays camping (think āglampingā in a luxurious caravan), which is completely different to the South African idea of camping (a tent in the bush). Knowing these differences in understanding is a step in the right direction to creating a harmonious team and mutual understanding.
Many books have been written about cultural differences, but one which I always recommend is The Culture Map by Erin Meyer.
No matter who you are, good communication is hard
Distributed teams are a fact of todayās life. They can be extremely beneficial if a little care and consideration is taken. Communication is the ultimate key to success, but it can be very challenging and requires a lot of dedicated time and intentional effort.
After-all, thereās a reason why there are actual degrees and courses in communication science!
Sander Voorwinden is a project manager and solution delivery manager at Entersekt. His passion is to explore new things, and new ways of working, as well as to empower his development teams to get the best out of themselves and always go the extra mile. Sander also enjoys spending quality time with his family, walking his dog, camping in his caravan, playing volleyball and biking. If you want to follow more of what he does, check him out on LinkedIn!
