Being a part of a team today is likely to mean that you’re working with people who could be at all ends of the globe. While the Agile Manifesto advocates teams working together, face-to-face, there are many real business reasons this doesn’t happen.
To name a few:
- Acquisition: For example, you’ve just acquired, or merged with another company.
- Team member availability: For example, you’ve searched far and wide, and the specific talent you need is in a different timezone.
- Local advantage: You’re developing a product to be sold in South Korea, and to really make this product successfully brought to the end customer, you need to establish a development team in South Korea to represent in the customer’s climate.
- New Market: You’re in FinTech and you’re wanting to expand from your home location in Germany to Singapore, and have no footprint there. Yet.
There’s a ton of research on distributed team challenges, from the several research papers I’ve pulled1, and from my own experience as well, the biggest challenge distributed teams face is to make sure everyone is all truly feeling like they are part of the same team.
So how do you make sure everyone feels like they are part of the same team?
When I get stuck with a problem, which should happen at least twice a day if I’m doing good work, one of my favorite tools comes from Peter Bevelin’s book “Seeking Wisdom: from Darwin to Mungar”.
In his book, about halfway through, he has a section called “Guidelines For Better Thinking”. There are 12 tools you can pull from this section, and my favorite tool, tool #10, is called “Backward Thinking.” The idea of Backward Thinking is to avoid what causes the opposite of what you want to achieve.
“Success in life and in business comes from knowing what you really want to avoid – like early death and a bad marriage” – Charles Munger
“You must always invert,” said the 19th Century German mathematician Karl Jacobi when asked the secret of his mathematical discoveries.
When we try to achieve a goal, solve problems, or predict what is likely to happen, or likely to be true or false, we should think things through backwards.
So now, the challenge to research becomes “What actions can we take to destroy this notion of feeling like we’re on the same team?”
Have this exercise in a retrospective if you can. Since you’re distributed, use a way to collect responses so that everyone can contribute equally from whatever location. Next steps are to affinity group (clump) the responses, give them headlines after they’ve been clumped, then as a larger team prioritize these answers. If something might already be happening in your organization, it bubbles to the top to be solved.
Some of the answers I’ve seen
We don’t feel like we’re on the same team because we don’t think our time is respected. The cause: the remote team isn’t allowed to set calendar times – when they do the calendar time is questioned, removed, or changed. When calendar times are set for when time zones overlap, it’s always the remote team bearing the brunt of the pain to meet in non-optimal times.
What would help: Agree to a time to meet and stick with it. Agree to a protocol when meetings cannot be met. And share the pain: if time zones overlap in a non-optimal time, alternate meeting times so all sites share the pain equally.
We don’t feel like we’re on the same team because we aren’t asked to be involved in the planning. What would help: From the earliest inkling of idea, involve everyone in the planning. Even involve everyone in iterating on the vision from the start.
We don’t feel like we’re on the same team because we are told what to do, and when we want to do something our voice does not have the same value. What would help to begin this conversation: Understanding norms of power distance and really talking about this openly. To get the dialogue going, suggest using Geert Hofstede’s wonderful tool based on results of his research comparing country cultures, with “power distance” included in this comparison.
Your answers will be context specific, not something anyone can predict. There’s no secret success pill for this, teams take work.
We are keenly interested to hear some of your answers and some things you’ve done to help make your distributed team members feel like they are indeed part of the same team, so please keep the dialogue going!
A Case Study of Coordination in Distributed Agile Software Development, Steinar Hole and Nils Brede Moe: https://link.springer.com/chapter/10.1007/978-3-540-85936-9_17
Using Scrum is Global Software Development: A Systematic Literature Review, E. Hossain: https://dl.acm.org/citation.cfm?id=1605521
Knowledge Sharing in Agile Software Teams, T. Chau, F. Maurer: https://link.springer.com/chapter/10.1007/978-3-540-25967-1_12
Knowledge Management Support for Distributed Agile Software Process, Holz, Maurer https://link.springer.com/chapter/10.1007/978-3-540-40052-3_7
Distributed Agile Development at Microsoft Patterns and Practices, Ade Miller http://www.microsoft.com/en-us/download/details.aspx?id=14916
XP Expanded: Distributed Extreme Programming, K. Braithwaite https://link.springer.com/chapter/10.1007/11499053_21
Fully Distributed Scrum, Jeff Sutherland https://pdfs.semanticscholar.org/cc92/5389cae2efac5ddfed32ebcabd37d2c7bcb4.pdf
Communication in Distributed Agile Development: A Case Study, M. Korkala http://ieeexplore.ieee.org/document/4301081/?reload=true
Essential Communication Practices for Extreme Programming in a Global Software Development team, L. Layman, L. Williams D. Damian, H. Bures http://www.sciencedirect.com/science/article/pii/S0950584906000024
Modified Agile Practices for Outsourced Software Projects, D. Batra.https://dl.acm.org/citation.cfm?id=1562200