How to Communicate Better in Distributed Teams

Distributed teams are the norm for many organisations today. Companies are global, communications technologies allow people to live away from the "office" location and many of the new workforce are nomads. Becoming a high-performing team is possible in a distributed group, it just takes more effort to overcome the inherent challenges of distance. 

This is the fourth in a series of articles which explores the impact of cultural differences on distributed teams - "Distributed Agile - how to work with teams across the globe". You can subscribe to receive notifications via RSS.

Introduction

Communicating within distributed teams is challenging for most people. Communicating with people in your own country with whom you share a language, culture, and many other similarities is already challenging. With people from another country, time zone, culture, and language, it is even more challenging. With any distributed project that does not proceed as expected, people often name communication as the main reason.

Remote communication can be both enjoyable and frustrating. I still love opening my PC, starting Skype, and talking with my colleagues from India, Indonesia, Ukraine, or Sweden. I find it exciting to share with my own development team in India the many things I have learned from talking with people who work in Latvia, Ukraine, and India. I enjoy having a Monday morning meeting with team members from three locations and deciding our strategy for the week. Collaborating with different  nationalities to complete projects is highly rewarding. At the same time, I have also been misunderstood as well as not understood what is happening on ‘the other side’. If one of my managers in India is unsatisfied, and I need to figure out what is going on, it is more difficult to resolve through Skype than it would be locally. Her perspective is also different from mine, so it takes skill and practice to understand. It is frustrating when you thought you clearly communicated your ideas for a certain function or design only to receive something that is entirely different from what you had in mind 2 weeks later.

Through practice, we learn how to communicate. This was true when we were kids, and it is still true as adults when we find ourselves in a new team with people from different locations who are using tools instead of face-to-face communication. If you focus on the frustrating part above, it becomes difficult. However, if you view it as enjoyable, you will find ways to make it work. If you are a strong communicator and/or lucky, and you have the right team that has remote work experience, communication may even work as if the team is in your local office.

In this article, we share experiences that can help you communicate better with your distributed team members. The structure of the article is based on our distributed agile framework:

[Click on the image to enlarge it]

The framework consists of 9 'bubbles':

1. Culture
2. Organization
3. Leadership
4. Product
5. Team
6. Architecture
7. Engineering Practices
8. Communication
9. Tools

Each of the bubbles has 3 elements:

A. Questions: a set of questions that organisations can use to assess their current state

B. Virtues: behaviors that foster distributed collaboration

C. Practices: things that have worked, shared by practitioners

We will use this structure to share what you can do to improve communication within your distributed team. But the first question is....

What do we mean by communication?

I think everything people do in business is some form of communication. We continually communicate in different forms (e.g., writing, speaking), through different media (e.g., email, Skype, Slack, Whats App Messenger), and on different levels (e.g., chitchat, operational, reflective, strategic). Communication is influenced by many subtle factors such as the participants’ cultures and accents as well as whether they are introverted or extroverted. Because communication covers such a wide spectrum with so many variables, focusing on communication per se is not the solution to making distributed collaboration work. We need to look at other aspects.

How does communicating with a distributed team differ from communicating with a local team?

In many ways, it is not different at all, and in other ways, it is very different. On an individual level, members of distributed teams lack face time in the office. Face time with your colleagues allows you the opportunity to bond and chitchat about things that matter to you. Because remote team members lack face time, we do not have the same chance to build strong bonds as those who see each other regularly, resulting in a weaker understanding of one another’s motives. Even if we use video conferencing to ‘see’ each other, we miss the emotional cues.

At the project level, we miss chatting at the coffee machine about the task we are working on together. We miss the brainstorming sessions about the product we are creating and the clients

we are serving. This lack of face-to-face communication has a strong impact on the level of understanding that remote team members have about the product, its purpose, and the clients who use it.

At an organizational level, we miss the inspiration gained from talking with the company CEO over a beer at Friday night gatherings. We miss the way the core values of the company influence the behavior of the people working within the onshore office.

To bridge these divides, we need to give more thought to remote communication. When we communicate with people in our office who are from the same culture, we do not experience (high) conversational barriers. However, when we speak with remote colleagues who are from another country, we have to think more deeply about the forms, media, and levels of communication we choose. Let us look more closely at how we can go about this.

Questions

To assess the current state of communication within your distributed organization, the following questions are helpful:

• Do we have a communication rhythm at different levels of the organization (strategic, operational, team)?
• What agenda do we follow in our meetings?
• How do we make (work) progress transparent?
• What type of communication is supported by what tool?
• Do we have emphatic facilitators?
• (How) do we substitute water cooler chat?

Virtues

• Align: create a communication rhythm at all levels
• Match communication modes with the right tools
• Facilitate the discussions
• Inclusion
• Transparency
• Openness

In order to make an organization agile, we need buy in and support at different levels, especially leadership and management. To make a distributed organization work smoothly, such alignment is even more important. On the team level, agile has built in meeting rhythms. It helps to add a communication rhythm at the managerial and leadership level; a quarterly strategic meeting, a monthly product ownership meeting are some examples. Alignment is key.

There is an abundance of tools for communication nowadays. Many people still rely on traditional media like email and phone calls and those are not always the most effective tools. Big enterprises also restrict people from using modern tools. We believe it's crucial to open up the possibility of using tools that can improve communication. Teams can self-select their tools. Or organizations can make matrices to match certain types of communication with the best tools available.

A strong facilitator helps create meaningful discussions. Distributed team members are often uncomfortable talking through video conferencing, in a different language with people they have never met. An effective team has equal 'talk-time' for every team member. Effective teams have a clear agenda and timebox for their meetings. A facilitator can ensure this happens.

Including everyone affected by a certain discussion topic in a meeting helps spread the right knowledge. As many remote people miss watercooler chat and customer interaction, it is paramount to include them in all important communication. Transparency being one of the key agile values, in distributed teams, we need to enable everybody to see what is going on. Sharing product vision boards, strategic plans, product backlogs, help spread important information across the distributed organization. Openness empowers people to help each other solve problems and create a better understanding between team members. Sharing everything that's important with your peers fosters effective collaboration.

Practices

From 'over the wall' to 'inception workshops', by Arjan Franzen

When I started becoming involved with outsourced software development, I worked for a medium-sized IT solutions provider. The teams we managed were located in India. Before we started, we were given a cultural sensitivity/how-to-interact-with-remote-teams course, and then we began working with the teams. I wondered what made this ‘over-the-wall’ way of working so dominant. I saw my colleagues operating in a similar way with their projects. This project management method can be summarized as a very simple customer-supplier type relation. In this specific case, it was also an internal relationship since both the India team and the NL team were part of the same company. The NL team can be viewed as the customer and the India team as the supplier. Essentially, the NL team was the intermediary between the ‘real’ customer (paying endcustomer) and the software developers in India. The solution provider built the software according to end-user demand. In my experience, this model is the simplest way to work together. However, this model is based on a number of incorrect expectations:

• In a relationship built on little trust, end-customers are expected to purchase a commodity in the form of software features.
• The specified requirements are sufficient to deliver a valuable product to users.
• End-customers expect the outsourced teams to ‘hit the ground running’.

These incorrect expectations need to be managed from the start. It turns out that the background for this ‘over-the-wall’ collaboration was by company design. The classic method of working was to create batches of work based on technical skills. This means that requirements are established first, then they gain approvals, and then they progress to the design phases, etc. Since this way of working was the standard, the end-customer intermediary team (our NL team) was essentially in charge of finding a solution for ‘the wall’. It may have been my first project with outsourced development; however, it certainly was not the project manager’s first. The NL team quickly set about managing the expectations and tearing down the wall.

Improving

We quickly learned that no amount of detailed specification (design or requirements) would render the exact software system you envisioned when writing the specifications. This means that there is a constant need for communicating with end customers (users, influencers, and purchasers). We needed to demonstrate a usable product based on the initial requirements. We had engaged the end-customers with per-feature communications about details, priorities, and designs. This approach solved 2 of the 3 project risks. There was, however, a challenge to this approach: the first workshop. This was the moment when the end-customer would realize how far along we actually were as well as how well we had understood their problem in the beginning. These initial workshops would take the longest with new customers, and we faced the risk of negatively influencing the end-customer relationship if we were not well prepared.

We learned to prepare these meetings in such a way that allowed us to uncover details that were not addressed in the initial specification. We included the entire team in the workshops, meaning we co-presented features and designs (if technical representatives were present) to the end-customer using a video conference solution to include the India team. We had taken steps not to separate development from design. This allowed feature design and development in lockstep. Achieving this was possible because we had established open communication and cultivated trust between all locations involved. Changing the way we communicated, from being focused on skills and phases to concentrating on value and features, ensured that we quickly gained a good understanding of the end-customer’s problem.

Inclusion: build effective communication on a foundation of trust, by Arjan Franzen

Sometime later (working for a software product company), I was able to take the things I had learned from previous experiences a step further. This time, there were differences in how the contract was set up. The country in which the outsourced teams were located was different (Ukraine) and so were the organizational arrangements. The remote teams were part of a different company—an actual supplier. We had made sure that we did not need an intermediary team in the Netherlands and decided to make the remote teams an integral part of the software development organization. The goal was to maximize the flexibility of the resourcing. When planning software releases, we must ensure that we are constrained as little as possible with regard to what team develops what release. These types of routing constraints can make a release plan an unsolvable puzzle.

Once we were onsite, we found motivated team members with many questions on their minds. We started immediately. We approached each team member as if he or she were a new

hire in our NL office. This helped us tremendously because trust is often lacking in new teams. We set up an introductory training program that detailed the technical environment and the market for which we were producing software. We specifically went for both technical knowledge and environment because this would help establish a sense of purpose for the remote teams. We spent about 70% of the time explaining the work processes, tools, and architecture. The remaining 30% of our time was spent discussing the business: who are the customers? What are their domains? At one point, I had made the mistake of including a slide twice in my presentation. It happened about an hour after I had shown the first slide to the team, explaining the architecture that was on it. I saw the mistake immediately but thought I would see how it played out. Would they detect the double slide, or would they quietly sit and politely nod ‘yes’ the entire time. I continued to present the slide for the second time. After 10 seconds, I was interrupted by the lead developer in the team: “I’m sorry Arjan; I believe you already went over this topic. Is that correct?” My trick worked! I was happy to discover that they were paying attention, understood what I had to say—and most importantly—they did not feel as if they had to suppress feedback regarding the quality of information provided (double).

After the first day of the course, we had dinner together and visited a local pub. This combination of training and discussions helped the Ukrainian team understand our situation. On our side, we began to trust the members of the team because we saw firsthand how they approached the difficulties involved with becoming familiar with a completely new environment. Discovering shared values between team members and customers helps greatly to establish basic trust between teams. This trust is the basis of a good working relationship.

Please note, “Your mileage may vary” regarding this procedure, depending on where you outsource your work. Even after enjoying a night of dinner, discussions, and getting to know team members better, the next morning, you may still find that cultural differences cause communications to remain unchanged - stifled.

Tools to spread knowledge and communicate company wide, by Rajiv Mathew

At the end of the day, software development is all about people. You need effective communication channels that help people work together to achieve the vision of your firm. Throughout the past decade, I have worked in the IT industry and have come across some wonderful tools that aid software teams with their communication challenges. Let us look at a few of them.

Newsletters

Sending a quarterly newsletter to the entire organization is very useful because it provides employees with an overall perspective of the company and its projects. Inviting the employees to contribute gives them a forum in which they can express their views. Similarly, newsletters regularly sent from the human resources, finance, administration, and marketing teams helps the development team gain a wider perspective of what is happening on the operational side of the company.

Intranet

The intranet is an effective tool for communication in the workplace. One of the companies I previously worked with used the collaboration platform Jive, which is an effective tool that enables developers to share best practices on projects. My current organization uses Yammer, another great option. The advantage to using these platforms is that they help with knowledge management. Think of it as a Facebook clone within an organizational setup. The intranet is the best place to share technical insights on various projects so that knowledge does not remain tacit in nature.

Company Websites

Even though the corporate website is an external-facing medium, many team members visit the website often for company updates and news. Featuring developers on the company website adds a sense of belongingness, and thus, increases employee engagement and retention. I have often posted press releases and multimedia on the corporate website and then sent links to the developers so they can read about what is happening in the company. If your onshore client has an extended team offshore, and you are a partner, a micro site can be used to communicate information to your team. I remember using Google Pages as a micro site to create and share information with a partner many years ago.

Storyboards

This is an excellent way to communicate the vision of a project or product to the entire development team. Even complex problems can be broken down into simple sketches so that everyone understands them. White boarding ideas and having developers use the storyboarding methods helps on all kinds of projects. If you have a distributed team, you can do this via Skype with online storyboarding tools such as StoryBoardThat.

Process Flow Diagrams

When developers build a platform, explaining the user flow or the process flow is extremely critical for understanding how the system is supposed to operate. Once the process flow is clear to the developers, the development would most likely be easy. This is where we also make use of wireframes to demonstrate the interaction flow using click-through prototypes.

Twitter

We have created hashtags for certain technical topics in the past, and then developers— including those from other companies—have provided multiple insights for solving problems. It is an interesting social experiment to try.

Live Feed

We were working on a big project that involved more than 100 developers, so we used Skype to start a group chat in which team members posted updates for the day, and people observed the updates on a big monitor screen. The entire experience worked much like the big TV screens in stock markets!

The 30-Second Rule

Another tactic that often works is to use the “30-second rule” while communicating with development teams. If you can respond to the message within 30 seconds, then you should do it. If you can respond to a developer’s query instantly, he or she will be more efficient. This holds true for any client-related communication. Faster replies make clients feel that you are fully engaged on the project and on top of things at all times.

A company wide communication rhythm, by Hugo Messer

Depending on the size of the company, people involved in remote collaboration communicate on at least three levels: strategic (CEO), process (project or process managers), and operational (scrum master and team).

Agile has a set of meetings scheduled on the operational level. The product owner, scrum master, and team members are involved in the sprint planning, demo, and retrospective meetings. The scrum master and team members manage the daily stand-up (involving the product owner when needed). I have learned that this meeting rhythm is absolutely crucial to and beneficial for distributed collaboration. When teams do not use this rhythm - especially the daily stand-up - things quickly slide down a slippery slope.

In most cases, the product owner is local, and the scrum master and team are remote. By following the scrum meeting rhythm, both shores automatically communicate daily. This increased communication creates the possibility to continuously adapt, remove hurdles, and create bonds between all team members.

In my company Bridge Global, We have learned that the role of process manager is crucial. We have an onshore account manager and an offshore process manager. Ideally, the customer also assigns a process manager (this can be the product owner or the manager who is responsible for the success of the collaboration). These three managers attend weekly Skype calls that last about 15 – 20 minutes in which they discuss alignment: Is the team on track? Are they communicating effectively? Are they still following the agreements that were initially made? What is going well, and what could be improved? This information is then stored (e.g., in Google docs or Atlassian Confluence) and shared with the entire team, so each week the collaboration improves a little more. We also give a grade on a scale of 1-10 that answers the question 'how happy are you with last week's collaboration' (back and forth!).

The top level communicates every 4 – 8 weeks. In the initial stages of collaboration, it is recommended that they meet at least once every 4 weeks. They discuss the progress of the strategic objectives of the partnership: Are the KPIs still on track? Are we providing value to one another? Do we have synergy? Do we work well together? What are the plans for future collaboration?

For example, a big Dutch/Swedish telecom company assigns a “change manager.” They always have one change manager from their company (local) and one from the partner’s side (remote). These change managers speak weekly. The product owners report to the change managers so they are always aware of the project dynamics. Every 3 weeks, the operational managers meet to communicate progress and the achievement of operational objectives. Every 6 weeks, a meeting is held at the strategic level. On every level, this results in continuous communication and adaptation and fosters deeper ties that result in a long-lasting partnership that increases in value as time passes.

Get the Key Team Members Together at the Beginning

Initiation of a project is very important for smooth execution later. In the beginning, newly formed teams are in the norming stage and they need some time together to collaborate and understand each other better. In distributed teams, this stage becomes more complicated because of not having people physically available at the same location.

As per communication richness theory shown below, face to face communication is the most effective communication channel. Hence, in distributed teams, we should always figure out ways to increase the face to face communication time.

[Click on the image to enlarge it]

Therefore to successfully kick-off an agile project, it is good to invite people from different locations and let them communicate face to face for some time. In the beginning, the team should work together on initial modeling, understanding high level user requirements, technical strategy and initial risk assessment. 

We should not stop doing face to face communication after the initiation. Time to time people should travel and meet physically and rotate team members between various locations, this might be expensive but leads to a high performing team.

Share the Pain of Time Zone difference

Agile teams practice multiple agile/scrum meetings, for example, daily stand-up, planning, review, retrospective and backlog refinement. We recommend to do joint meetings and share the pain of time zone difference by rotating either getting up early or staying up late.

After staying late for a long time, people start missing the meetings and hence, bad impact on team communication. I have seen many teams in this situation and figured out the pattern that after initial few sprints, team members start hating daily stand-ups or other meetings for which they need to stay late for a long time.

Find out a common language of communication

People can not communicate each other properly if they do not understand each other's language. It is very crucial for the team to find out a common language for the team communication. These days, though English is the most commonly used language all over the world but there are some exceptions, for example, Japan, China etc. In these scenarios, there are few options:

1. Learn a new language: encourage the team to learn another language. However, many times people are not open for it and it is also difficult for them to excel in the new language in short amount of time.
2. Use translator: the team can use a translator who can speak required languages but a single translator could create more dependency and blocker in effective communication. Additionally, this option is expensive too.
3. Use translation tools: there are many good translation tools available in the market which the team can use while doing conversations.

Sometimes, even after finding out the common language of communication, people can not understand the accent of each other. To overcome this challenge, companies give training on listening and understanding accent of people from different countries.

A Guide to Sprint Retrospectives with a Distributed Team, by Realtime Board Team

As teams become more distributed, running Sprint Retrospectives becomes challenging. But this is not a reason to quit doing them. Here are some tips from RealtimeBoard and Lieuwe van Brug from Lerni.io, who has practiced running retrospectives with distributed teams many times.

Step 1: Attendance and Engagement

Be creative and surprise the team while organizing the retrospective — you’ll get a lot of different feedback.

Retrospectives are a lot about emotions, attitude, etc. This is easily lost in a distributed environment. To solve this — partially — you could use good cameras and make sure everybody is visible during the retrospective. Asking more explicitly on emotional subjects can improve the situation as well.

Step 2: Sprint Review

Choose subjects you want to focus on during a retrospective. One subject per sprint. If you focus on different subjects every sprint, you donʼt get the same problems mentioned every time.

Step 3: Discussion

Itʼs important to catch everyone’s opinions. One of the things you can do is to give everybody a personal part on RealtimeBoard. Copy the visuals you are going to use during the retrospective per person and let every person zoom in on their personal part of the board. In the discussion rounds you assemble all input to a central place on the board. This way you make sure everybody is heard.

Step 4: Actionable Commitments

Make sure that you prioritize what to solve in one sprint. Small achievable goals work better and are sustainable over longer periods of time.

A tool that will help you to go through all these steps with the distributed team is an online whiteboard. It offers all the benefits of a traditional whiteboard, while giving all participants an unhindered view with the ability to add and edit information in real-time. To start your next retrospective, just choose one of pre-made templates, some of which are discussed below.

Template 1. Start, Stop, Continue

Participants identify actions that they want to start doing in the next iteration, and those from the previous iteration that they want to stop doing, or continue doing.

[Click on the image to enlarge it]

Template 2. Glad, Sad, Mad

Each participant is then given the opportunity to describe their observations and place it on a whiteboard. The whiteboard is divided into three areas: Glad, Sad and Mad.

[Click on the image to enlarge it]

Template 3. Sailboat

Here a Sprint is compared to a sailboat. The team records things that helped the Sprint move forward or slowed it down and place them either on the sail or below the boat, indicating that they are anchors or wind.

[Click on the image to enlarge it]

You can read the article in full, find some additional tips and pre-made templates on the Realtime Blog.

About the Authors

Savita Pahuja has expertise in Scrum, Lean, kanbanareas and other visual discovery methods. She started her journey in IT industry as a developer and contributed the organization in agile adoption. Then she moved into agile world as a consultant and trainer. Since then she has been working with different clients for agile adoption and giving trainings on scrum and kanban.

Hugo Messer has been building and managing teams around the world for over 10 years. His passion is to enable people that are spread across cultures, geography and time zones to cooperate. He's the owner of Bridge Global, a global software powerhouse and ekipa.co, the education platform for distributed teams.

Since Arjan Franzen became familiar with Agile, DevOps and Lean, he's been very excited about these innovations in software development and try to apply them in his professional environment as much as possible. Because he is passionate about this new way of software development he started his own software company: ZEN Software. By providing consultancy services on topics like Delivery pipelines, DevOps, Continuous Delivery and Lean software development, Arjan wants to enable companies to minimize risks of software releases. With minimum risk per release, the release frequency can increase. By applying Lean (and Lean startup) principles, it must be possible for companies to measure effectiveness and value in software changes: "Build the right thing". If companies build the right software (demand), and build them correctly (quality) they get meaningful software deliveries; "Purposeful software delivery" - The Motto of ZEN Software.

Distributed teams are the norm for many organisations today. Companies are global, communications technologies allow people to live away from the "office" location and many of the new workforce are nomads. Becoming a high-performing team is possible in a distributed group, it just takes more effort to overcome the inherent challenges of distance. 

This is the first in a series of articles which explores the impact of cultural differences on distributed teams - "Distributed Agile - how to work with teams across the globe". You can subscribe to receive notifications via RSS.