I have no doubt that everyone who has worked in a distributed team throughout their career had difficulties of some sort. Many people say that such teams can never be really successful. This is usually caused but not limited to cultural and time zone differences, lack of trust and face-to-face communication. I have been working with such teams in the past several years and I can share that I have experienced all of the above. However, I do not agree with the statement that such teams are destined to fail.
Several weeks ago I took part in an interesting discussion related to this topic at the ALE 2015 conference in Sofia, Bulgaria which turned out to be quite productive. Together with my colleagues, we have managed to identify some of the main reasons behind the failure of distributed Scrum teams.
Everyone is unique and has his own understanding of the world. When we consider the fact that countries differ strongly on customs and religion, it is a small wonder that people often do not get along that well, especially in the beginning.
A single sentence can have three different meanings if the person is coming from Asia, Europe or South America. Another example is the fact that a simple nod which usually means “Yes” in almost every part of the world means “No” in Bulgaria. Imagine how awkward this can be in certain situations. I do not want to touch the religious differences as the topic gets a lot more complicated.
And now what will happen if a Scrum team consists of Americans, Germans, Bulgarians and Indians working on multiple locations worldwide?
Face to face communication
Long video calls via Skype, Google Hangouts, Lync or whatever tool you are using. You are starting to feel nervous and desperate that the person on the other side does not get what you are saying. You end the conversation with the agreement that you will continue later or on the next day.
This is quite common when the team is not co-located. The lack of proper visual contact limits the participants to count mainly on their speech. It is tough even for native speakers, not to mention people from different countries.
Time zone differences
The time difference can seriously damage the team’s effectiveness. It happens quite often when you have colleagues on different continents such as Europe, North America and Australia. If you get only one or two hours of working together at the same time, it means that all important conversations should be done in this time period. As it is usually not enough, this leads to overtime and eventually people start to feel annoyed and burned out.
Lack of trust
“Trust is a must for success”
In a Scrum team, the lack of trust can easily lead to a “WE against THEM” situation. It is a recipe for disaster which can destroy the team’s morale. Once you go there, you can be more than sure that you will eventually fail.
So how can we limit the damage? Here are several suggestions:
Looks obvious, right? I know that your first thought would be “Yeah, sure…”. While in most cases this will not work due to other factors that determine the need of having distributed teams, it still makes sense to give it a try. Maybe the people responsible for the distribution were not aware of all the negatives that go together with their decision and they were just looking at the financial figures.
What do you have to lose?
Get the team in one place as often as possible
If eliminating distribution is not an option, try to get the whole team in one place as often as possible. This will give them the opportunity to work face-to-face, go out after work etc. The team spirit will definitely benefit from it.
The Product Owner should travel as often as possible
The bare minimum in terms of co-location is for the Product Owner to spend as much time as possible with all team members. As the Product Owner usually sits together with one part of the team, the other members might start to feel isolated and neglected. A perfect example for a “WE against THEM” situation.
Use Scrum ceremonies effectively
People tend to keep their feelings and not share them with their colleagues. When you don’t have visual contact with your team members and you only speak for several minutes during the daily Scrum meetings it is really hard to understand how they feel. This is why it is vital to use Retrospectives and other Scrum ceremonies where you can share what is bothering you and how it can be improved. This is also where the Scrum Master steps in.
Learn to say “I did not understand that”
As mentioned above, misunderstandings can occur more often when you are in an online meeting. If you are not fully convinced that you understood what the meeting is about or what was its outcome, go for it and share it. You might feel anxious and embarrassed at first but it can greatly help you and your team in the long term.
Get familiar with the culture of other team members
When you make an attempt to learn more about other people’s culture, they will definitely acknowledge that as an act of respect and will most likely be more open to you. A good example will be to use a new word in a language that is not common for the whole team every week during the daily Scrum meeting.
Be as friendly as possible
Try to be as friendly as possible whenever you speak to a colleague. Start the conversations with something personal like a question about what is the weather in the place your colleague is located, what did he do during the weekend, did his favorite football team win etc.
While this will not work on everyone, most of the people are likely to respond positively.
Use a local Scrum Master
One of the problems with distributed teams is that team members cannot benefit in the same way of their Scrum Master. It might prove useful to “appoint” a local Scrum Master who can help with resolving issues that are relevant for his particular location only. This person can also share people’s problems with the rest of the team which will ease the overall communication.
Although the effectiveness of distributed Scrum teams can be increased by implementing some of the suggestions written above, I strongly believe that such teams can never be as good and productive as co-located teams. After all, life is not ideal and we need to have the ability to adapt ourselves.
I call this “the art of being agile“.