Can your Scrum team be geographically distributed?
What are the challenges of offshoring and outsourcing in Agile environments?
How can you benefit from agile when your squads are geographically distributed?
How can we implement agile frameworks in multi-vendor teams across multiple offices?
In 2016 I had the privilege of presenting in the Scrum Australia Conference on setting up distributed multi-vendor Agile teams. Scrum Australia is the foremost Scrum event in Australia and is the only Scrum Alliance endorsed conference down under.
According to the 12th State of Agile report, distributed Agile is becoming the norm in the industry with almost 80% of the respondents having at least one team practising distributed agile. When Agile manifesto was developed about 20 years ago, distributed teams were not as prevalent as today. With the technological advancements of the past few years, nowadays, distributed teams and outsourcing is a viable solution for accessing specialised skills, cost saving, and risk management.
Now the question is how can we fully embrace the values and principles of agile manifesto in a distributed environment? In particular, how can we maximise collaboration, communication, trust, transparency, empiricism and everything else Agile stands for when team members do not physically sit and work next to each other?
As eloquently described by Dantar Oosterwal, modern day product development can be described as the “process of converting uncertainty to knowledge”
The speed and quality of product development depends on the bandwidth of communication between team members. When I attended Alistair Cockburn’s Heart of Agile course in 2016, one of the first activities we did was to identify what slows down the movement of ideas between minds? Then this list became our improvement backlog; the list of impediments to remove so we can speed up the movement of ideas between minds. Effectively increasing the communication bandwidth.
“Communication is like perfume it gets stronger the closer you get” ~Alistair Cockburn
Research has shown even 10 meters of distance between team members decrease the level of collaboration significantly, let alone different geographical locations. There is a theory called media richness theory This theory categorises various communication mediums based on a richness metrics. To define richness we consider factors like:
- Medium’s ability to handle multiple information cues simultaneously
- Medium’s ability to facilitate rapid feedback and near real time information exchange
- Mediums ability to establish personal focus
At the top of the spectrum we have face to face communication next to a whiteboard. And at the bottom of the spectrum we have emails and documents.
In distributed environments we don’t have the luxury of face to face communication so we have to settle for the next best thing which is high quality video conferencing or video recording messages (in case of time zone differences)
Making sure communication takes place is super important but it is not enough. We also need to make sure the quality of communication is good. We need to make sure there is transparency and trust in the team.
Building trust in distributed teams is very challenging. People naturally build trust when they live and work together and interact on daily basis. Human beings are social and it is super important to spend time together to build trust.
Lower levels of trust, fear, and lack of transparency are very common symptoms when there is a client/vendor relationship. Particularly when there are multiple vendors involved. It is of upmost important for coaches to keep a watchful eye on trust, transparency, and fear levels in these situations. Coaches must measure and proactively work on establishing an environment of trust and transparency where people are not afraid to speak the truth and to make mistakes.
In my opinion when there is a client/vendor relationship one of the biggest enemies of trust is trying to be too perfect. We are all humans and we make mistakes. Rather than trying to be political, and point figures, if we take responsibility for our actions and acknowledge our mistakes, people will respect us more and this will increase the trust levels significantly
After all, the Agile Manifesto values customer collaboration over contract negotiation, and individuals and interactions over processes and tools.
When working in distributed teams it is quite common for locations to be in different countries. In these situations cultural differences create another impediment for maximising communication and trust levels.
For example some cultures perceive asking questions as a sign of incompetence.
Let’s say you are talking about a very important topic in a meeting room with a few colleagues. And a developer from your vendor has dialled in from an offshore office. They probably do not have the context as much as you do, they do not have the deeper business understanding of the topic. They can’t see your body language, English is their second language, and they can’t hear you well because of low quality of the call. Compound all these with a cultural tendency of not asking questions because they don’t want to look incompetent in front of an important client.
I believe in this situation the onsite person is responsible to make sure the offshore person has fully understood what was communicated.
Another example is that some cultures perceive saying “no” as a taboo. Especially to people of higher status (e.g. boss, client, etc). In these cultures you have to understand from body language when yes means yeas and when yes means no.
Let’s say you ask your team “is it possible to deliver this user story in the next two weeks?” and they say yes sir of course it is possible. Then at the end of the 2 weeks nothing is delivered. And when you follow up and you hear irrelevant excuses. Have you ever been in that situation before?
If someone understands this culture they will know from the body language that even though they said yes they really meant “Are you crazy? This is impossible”
Again in this situation I believe it is the responsibility of the onsite person to make sure they learn the body language of the offshore culture and understand the way they communicate.
Cultures don’t change overnight and if we want to succeed in globally distributed agile business we need to fully learn and embrace the culture of our off shore teams. As coaches we need to educate both onsite and offshore staff about the importance of taking cultural difference into account and to think about them in our day to day activities.
Lewis cross cultural model provides in depth analysis of business cultures across various countries.
What can we do about it?
Below is a list of pragmatic things you could experiment with to make things better in your distributed agile teams.
1. Office setup and technology
Office set up is a key in providing an environment which promotes collaboration in distributed agile teams and squads.
The image above illustrates how a typical distributed squad work environment looks like at both locations. There will be an always-on video conference link between the locations (e.g. BlueJeans session). Wide angle webcam makes sure not only the entire team area is visible but the actual physical board is also visible at both ends.
We promote using both a physical wall and a virtual wall. Some aspects of the wall may be replicated according to the squad discretion but it is not required to replicate everything. For example the physical wall may have the squads charter, goals, vision, agile educational posters etc. and not just the kanban board.
With this setup, people can see each other and can walk up to the camera and wave if they need to talk with someone. This setup highly encourages collaboration and communication in a distributed environment. It makes talking to your offshore peers as easy as emailing, messaging, or calling them.
The image below shows an example of similar set up. Even though this is a low resolution image you can clearly see facial expressions and body language of the offshore team. You can clearly understand who is talking and who is looking at who. there are multiple information cues available simultaneously.
For longer meetings where in depth conversation is required, distributed meetings can happen in meeting rooms with the following set up.
2. Frequent travel
Frequent travel is one of the biggest investments you can do when setting up distributed agile teams. Travel means people get to know each other, build relationships, establish trust, and get to learn each other’s cultures.
The best way to understand the pains and challenges of offshore teams is to go offshore and do your day to day work from their location. Only then you will understand the hoops they have to jump through just to do their day to day work.
This means we will appreciate their situation and take it into account when working with them. This kind of empathy significantly increases collaboration and communication quality as we will know when there is a higher chance of misunderstanding.
3. Have trust budget
This budget is protected and is spent by the program on what they see fit as a trust building solutions. For example the trust budget can be spent on travel, social activities, distributed hackathons, distributed charity works by the squads, and other distributed team building activities.
Distributed teams need to spend more days on team building activities compared to co-located teams. Some examples of distributed or virtual team building activities can be found here:
https://inside.6q.io/unusual-remote-team-building-activities/ https://museumhack.com/virtual-team-building-for-remote-teams/ https://www.teambonding.com/5-team-bondingtips-for-remote-employees/ https://realtimeboard.com/blog/remote-team-building-activities-games/ https://www.eventwise.co.uk/team-building-ideas-for-remote-teams/
In distributed teams we have to go out of your way to build trust with offshore teams. Again, I believe travel is the single most important thing you can do to build trust in distributed teams and to improve collaboration by appreciating the challenges of the other side.
We may have all the skill required for effective in person communication, but that does not mean we are an effective online communicator. We need to invest in educating our team on how to effectively communicate on teleconferences, videoconferencing, and chat rooms.
I found teleconference meeting etiquette training quite useful. Things like making sure people talk to the teleconference microphone instead of talking to each other. When we are talking to the phone we talk differently to when we talk to a person face to face. We use different information cues to make sure the person at the other end understands us. When in a meeting, even if we are talking to the person in front of us we must actually pretend to talk to the phone. This makes sure the person at the other end understands what we are talking about and they don’t get lost.
Cultural education is also super important. We must educate our team what are the cultural difference of various locations. The offshore team needs to understand the onsite culture and the onsite team needs to understand the offshore culture.
Saying something is only 50% of communication. We need to make sure the person at the other end has understood what we were trying to communicate. And this is only achievable when we have understanding of each other’s culture.
I believe there is one situation when it is almost impossible to make agile work in distributed teams. And that is when each location is grouped by skill. For example all your developers are on site but all your testers are offshore. This creates silos that are further reinforced by geographic separation.
Having cross functional teams is one of the most important underlying philosophies of Agile. So the single most important thing to do in distribute agile is to have cross functional teams at each location. This is absolutely the most important takeaway from this blog. DO NOT CREATE SILOS AND PUT THEM IN GEOGRAPHICALLY SEPARATE OFFICES.
If you have such silos try to at least add one person from a different department/chapter to balance out and create some cross-functionality. E.g. if your business analysts and Product owners are onsite and your developers and testers are offshore, send one Business analyst to offshore and bring in one developer or tester onsite.