Being Part of a Team. Really.

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 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 backward.

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.

The 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 the 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 the results of his research comparing country cultures, with “power distance” included in this comparison. 

Your answers

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!

Research on Distributed Team Challenges

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 in 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

Catherine Louis

Catherine Louis is a Certified Scrum TrainerTM, independent Agile coach, and co-founder of the #PoDojo, who lives in North Carolina. With over 20 years of experience in complex product development in both software & hardware, Catherine has previously led Agile transition efforts in top telecommunications firms and worked with North Carolina State University to conduct research on Agile Test-Driven development. She has conducted years of research and training on “building security” into your product, verifying that security protection mechanisms are in place and working before it’s too late. Catherine regularly speaks at Agile20XX conferences, is a lead for the “Working With Customers” track, and runs the AgileRTP meetup group, one of the largest Agile meetup groups in the US.

https://twitter.com/catherinelouis
Previous
Previous

Tomer Sharon: The Mindset You Need to Develop Products People Desire

Next
Next

5 Common Unconscious Biases We See in Product Development - Bandwagon Effect