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.

The past decade, I’ve been learning how to manage distributed teams in a productive way. In 2004, I made a trip to India and fell in love with the country. I had decided to start my own company and one of the ideas I had was to offer outsourcing services to Dutch companies (I’m from Holland). In the early 2000s, it was mainly US enterprises outsourcing to India. In Europe, just a few pioneers were taking their first steps. When I walked around in India, I was amazed by the energy the IT industry had at that moment. I did see that as a Dutch, there’d be some challenges in working with people from such a different culture.  To make it ‘easier’, I decided to work with teams in Ukraine at first. But my dream was fixed: I wanted to get back to India, set up my own company and make it all work.

I made miserable, costly mistakes along the way. When I started out in 2005, there was no scrum and agile (they were there, but not used by many companies yet and I was not aware). Everything was fixed dates, price and traditional project management, waterfall based development. I figured that if I would hire a project manager in Amsterdam to work with customers locally and manage the teams in Ukraine, it'll all work out fine. Of course it didn't. In hindsight, my rule of thumb is that with project based work in a waterfall model, 80% of projects go fine (with some small delays here and there). 10% you'll finish but with a lot of extra effort. But then the last 10% become the headache. You need to put all your highly skilled guys on it in order to finish the project without getting sued. And this derails everything (not only for you, also for the customers).

In later stages, I started experimenting with dedicated teams working on products, not projects. That worked out a lot better, because you can create 'one team' across locations and organizations. You can use agile and scrum to manage the collaboration. Based on my positive experience within the last years, I've written a series of books about managing remote teams. This is a collection of practical stories written by practitioners across the globe. But I believe our industry needs more.

Today, there are many agile frameworks, scrum clearly being the most popular. Scaling frameworks are gaining in popularity. Many frameworks tell us that collocation is the best. And I couldn't agree more. Unfortunately, that's not the reality many companies operate in. In order to fill that gap and give people a framework to manage distributed teams, I've started developing a distributed agile framework together with 3 others: John Okoro, Savita Pahuja and Arjan Franzen.

We're still in the inception phase. Our belief is that we should open source a big part of the framework. That includes getting feedback on what our 4 brains have spun out at very early stage. The framework we have developed consists of 8 'bubbles':

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

Each of the bubbles has 3 elements:

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

B. Virtues: behaviors that foster distributed collaboration

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

In our experience, the 8 bubbles are the buttons people can push in order to make distributed work smoother. It's a continuous cycle of improvement. The impact of each bubble varies with the size and complexity of the enterprise and the maturity of the distributed organization. To decide what the pain points are and what bubble to focus on, our framework provides an extended set of questions. We then define virtues that help within each of the bubbles. The virtues help create a 'distributed agile culture', a set of guidelines for behavior. Many people will at that point ask 'so what do I do now?'. Our practices help answer that question. Every context is unique. Learning from what has helped others is in our view the best way to find solutions to specific distributed challenges.

Together with my co-contributor to the framework John Okoro, we'll take you through 2 of our bubbles: culture and organization. In subsequent articles, we will describe the other bubbles in more detail. The articles will be published as an InfoQ minibook.

We also seek the comments, and feedback of our readers. As mentioned above an open source model is at the foundation of the distributed Agile framework. The framework is based on a foundation of Lean and Agile principles.

Culture

Distributed teams with people from different cultural background inevitably face collaboration challenges. Culture has multiple levels (country, region, company, team). In our model culture refers to the country level. Organization and team are discussed in separate bubbles. To understand the impact of cultural differences and find ways to organize them, the following set of questions can be used:

• Are we experiencing impact from cultural differences?
• Do we have an 'us versus them' paradigm?
• How do we deal with differences?
• What will we do to get the differences to the surface?
• How comfortable is each culture with being open, sharing matters of mind and heart?
• What's the impact of cultural differences if we're collocated versus distributed?
• How much hierarchy do we have in our organization?
• How does each culture perceive hierarchy?
• How much 'self organisation' do we expect?
• What can we do to get everyone on the same level of 'self organization'?
• To what degree does language have impact?
• Does everyone have the same understanding of saying 'no'?

Some examples. Most countries vary in the degree of hierarchy that governs families, society, companies. In many Asian countries, hierarchy plays a big role. People are used to having fathers, teachers and bosses give 'instructions'. Because of that, the level of 'proactiveness' is often low. Questioning authority and challenging superiors assumptions is not done. In the US and Europe, many countries have a 'flat' structure. In the Netherlands as an example, people are expected to question assumptions and encouraged to come up with their own ideas. It doesn't matter what level within an organization the idea originates from. Hofstede’s model calls this ‘power distance’. Countries are ranked based on some complex metric system. From this overview you can see for example that India (77) and Indonesia (78) rank very high, whereas the Netherlands (37) and the US (40) score lower.

Another example is the level of openness. As a Dutch person, if I have a problem with the way you behave, I will tell you what's on my mind. My belief is that by sharing my concern, we can find a way to solve it together. In Asian societies, people are not used to this. They'd rather polish a story, speak around the concern they have without addressing it heads on. As a Dutch I might not understand the message the person is giving me because I am used to getting it unpolished, straight into my face. This causes tensions in relationships and strains collaboration.

Last week, Hugo organized a meetup in Jogjakarta, Indonesia. One of the topics we discussed was openness, as it's one of the values of scrum. Hugo was facilitating a discussion with a group of about 25 people, all Indonesian. As is common in groups, there were a few outspoken people. Now there are many forces at play on the topic of openness: some people are shy and don't like speaking up (are less open); some people are comfortable speaking English, some are not (so they appear less open, but might 'pop open' when they speak their own language); some might consider it rude to speak up because of their role within the group. As a person, Hugo is used to this (in India he had similar experiences and worked with different cultures for over a decade). But when an unexperienced Dutch person (who's often outspoken and direct), needs to collaborate with Indonesian engineers, it will give challenges.

We have defined 5 virtues that help bridge cultural gaps:

• Empathy: accept differences, 'jam' with them
• Openness: discussing the impact of cultural differences
• Awareness: becoming aware of the differences
• Trust people more than process
• Transparency

People with empathy have a higher propensity to put themselves in the shoes of another person. They can live into another person's reality, understanding his or her beliefs, reasoning, frame of reference. They are also more inclined to accept differences among people. And they often appreciate the diversity, playing 'with' them instead of against. Distributed collaboration is facilitated by emphatic people. This implies that having some people with empathy in each team helps. One specific role that requires empathy is the scrum master.

The degree of openness about concerns, lack of information, delays, being 'stuck' influences results. The more open an organizational culture becomes, the easier it is for people to collaborate. It also leads to increased awareness about cultural differences, a team's 'state' and work progress. Most knowledge work is creative and doesn't fit into a step by step process. Success depends on the people engaged. Managing cultural diversity becomes easier when you have the right people that trust each other on board. Tools can help them self-organize the differences, processes don't.

Transparency enables people to inspect and adapt. When all the information and progress of a project is shared with everyone, it leads to less misperceptions. When I know the progress on a commitment, I don’t need to rely on the yes or no (which is culturally subjective) of a specific person. When tools support our communication about specific user stories, it’s easier to get the correct information in time.

In the above example of my group discussion, I consider myself to be empathic. As a facilitator, I am aware of the different levels of openness in my group and I also respect them. It's OK. I try to be open, but not blunt. I also trust that everyone is doing the best he or she can, which means that some people absorb the discussion without talking, some share openly and dominate the discussion. I try to engage everyone in the talk as much as I can, but also realize I should learn Bahasa Indonesia in order to lead such discussions more effectively. This was a temporary group and if I'd need to work with them on real projects, I'd need to accept that it will take time to create balance in the group.

Organization

Enterprises are becoming more distributed as technology facilitates global collaboration. People start working from home and projects are distributed over different locations. To orchestrate the work, across locations, agile principles help. Interaction between team members and stakeholders are frequent and based on patterns. The stakeholders, users or customers are close to the development teams. Organizations create roles, events and artifacts according to the scrum framework. But it's not always easy to decide what role to place on what location or how to coordinate events with people in different time zones. Not seeing each other in an office creates challenges in alignment. It's also not necessarily visible how each team (member) is performing. The following questions can be asked on the organizational level:

Questions

• What software development framework(s) do we adopt? (scrum, LeSS, Kanban, SAFe, etc)
• How do we modify the framework to fit our distributed setup?
  • Roles: what role where? (e.g. proxy product owner)
  • Events: what's different in the events we organize? (e.g. video recording if timezone difference doesn't provide overlap)
  • Tools: what tools support the framework distributedly? (e.g. JIRA versus sticky board)
• Do we create dispersed teams (everyone remote or split teams) or collocated teams?
• How do we measure success? What are our kpi's?
• How do we share knowledge effectively across all team members?
• How do we share product vision, roadmap, user feedback?
• How do we align on strategic, tactical and operational level if we work in partnerships?

One of the main challenges in distributed agile teams is the availability of the product owner and the stakeholders. Teams are often in the dark, because they are not available. Product people are among the most busy in every organization. They need to balance their time between development teams, stakeholders and management. They are often part of multiple product teams. Teams that are collocated with product owners have a higher chance of interacting with them. But a remote team lacks that opportunity. What's more, remote teams hardly speak to users of the software they create. They don't have access to product vision, roadmap and related plans. Hence, they have no 'emotional bond' with the product they make and this influences motivation and quality. Organizations need to think through the distribution of key roles and the way development teams can engage with users and stakeholders. We also need to think how to share knowledge and product information throughout the distributed organization.

To create productive distributed organizations, the following virtues help.

Virtues

• Agility: keeping an open mind in respect to models; avoid bureaucracy
• Self organization: let teams figure out stuff
• Collocated teams are simpler
• Direct access to stakeholders: avoid the middle man (a product owner facilitates team-user interaction instead of being 'in between', no team leads, no hierarchy)
• wiki is key; sharing knowledge, visions, feedback using the right tools
• Cross-functional teams at different locations
• Aligned agile transformation vision at different locations
• Kaizen instead of Kaikaku

Applying these virtues to the 'being in the dark' example described above: we can use agile principles to organize. Instead of creating strict rules and reporting systems, we move authority to teams. Through retrospectives, teams can find what blocks them. Empowered, self organized teams can openly communicate those blocks to product owners and stakeholders. Through good product ownership and iterative improvement, teams will find ways to share product information, roadmaps and user feedback.

Business people and developers collaborate on a daily basis. This avoids the product-owner-becoming-middle-man problem. Using video conferencing software or collocation, developers can interact with the users and stakeholders. It helps if organizations stimulate teams to use wiki-like tools. Making those freely available, it becomes easier to share product visions, roadmaps and related documents.

Another key organizational area to be aware of in distributed Agile is not trying to do too much too fast.  In Japanese this is known as Kaikaku or radical change.  This may mean upending all of your teams and changing all of their job titles and roles just to try and fit into an Agile framework.  This can often cause change fatigue in your organization and prevent teams from being effective, and rather trapping them in a constant cycle of "forming" and "storming" (teams typically go through a cycle of forming, storming, norming and performing - the preference is to be in the norming and performing as much as possible).

In a recent case John is familiar with a large bank tried to adopt Agile across its locations using a kaikaku approach.  Renaming all of their managers to Agile coaches (though they knew little or nothing about Agile), and making many other large and traumatic changes in one fell swoop.  While the bank initially felt that they were making great progress with Scrum, it was a matter of about 18 months before the organization and teams hit the wall in terms of change fatigue.  After that significant resistance to the change became apparent and forced the bank to significantly roll back the aggressive pace of its changes. The bank thereafter moved to a healthier kaizen (continuous improvement) pace in its adoption of enterprise Agile.  As far as John knows this has been much more sustainable in the bank and continues today.

A recommended approach is rather to try and use a kaizen (continuous improvement) approach to changes.  Rather than attempting to change everyone's role and title in the organization make small incremental changes that improve the distributed Agile team as you go.  Your team's will appreciate this, and it shows respect for people (a frequent pillar in the "Lean Thinking House").  As a general rule of thumb the primary scenario where Kaikaku or revolutionary change is effective may be in a new organization or start-up where there is no or very limited organizational "baggage" to deal with.

Summary

Distributed organizations face challenges that don't appear when everybody is collocated. Some challenges also occur in collocated work, but the impact is smaller. Our framework summarizes the main challenge areas into 8 bubbles. We've described what occurs in 'culture' and 'organization' when people and teams are working remotely. To guide people in assessing their organization, we've laid out a set of questions within each bubble. In later articles, we will share the other 6 bubbles. We would be happy to receive your feedback on the framework and the questions and virtues we have developed (hugo@ekipa.co or leave a comment).

About the Authors

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. 

John Okoro is the creator of Auspicious Agile and he has founded Agile services practices for Rally Software in Asia and for a US management consultancy.  With nearly a decade using Agile methods, John is an expert at using Agile practices and methods at Enterprise scale and in large and distributed organisations.John is a frequent speaker at Agile and industry conferences and an InfoQ contributor on DevOps.  John has consulted in the telecommunications, entertainment, real estate, information services, financial services and professional services industries for numerous Fortune 500 companies including Disney and Accenture. He is experienced with start-ups, entrepreneurial ventures and working with US government clients.  John also teaches on Agile Scaling at National University of Singapore (NUS).

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.