The past couple of months, I have been thinking about a method for larger scale distributed work. I envision how productive distributed teams could be if this method worked. Teams could gather, create a ‘map’ for their collaboration and once aligned, login to a dashboard where they can select the cloud-based tools they need for their project. Because they did some cultural exercises, they fully understand the perspectives of one another. They follow an agile based collaboration process and update all stakeholders in the dashboard. Everybody’s aligned and updated and high quality software is delivered.
There are a couple of challenges, though. First of all, the method and dashboard don’t exist yet. Second, software development is a process based on people. People behave unexpected, change their requirements, make mistakes and do whatever they like. Thirdly, the process is highly creative, nothing linear about it.
Because ‘agile’ has shown the software industry that things can be done much better, I believe we could create a similar ‘methodology’ for distributed work. I see many people struggle with making outsourcing, offshoring and nearshoring work. Everybody is learning by trial and error. With a method, people could skip the error.
There are a couple of particular challenges distributed teams face as opposed to collocated teams:
1. Cultural Differences
In most cases, a distributed team consists of people from different cultures. And cultural differences often bring problems in understanding between people. The differences are often not apparent and miscommunication happens beneath the surface.
Part of the team is far away. I can’t ask my colleague next to me what he’s working on today or if he can help me solve a problem. But still, I do get stuck on certain points and I do need to align with my teammates to complete work. I also can’t see the sticky notes on my scrum whiteboard. And I can’t really ‘see’ what someone means when I speak with him on the phone or video conference.
It is a challenge to communicate successfully across globally distributed teams; these are the few lessons from Twitter, which has offices around the world!
3. Creating A Sense Of ‘One Team’
People don’t meet up regularly; sometimes teams have even never met in ‘real life’. Distributed teams miss the coffee chat, lunch talk and friday night beers. Without meeting up, the human bonds we forge when we meet up, don’t develop naturally. This has an impact on trust and understanding within a team.
When everyone is in one office, it’s sort of easier to understand how the team works. If there’s a formal process, the team discusses and reviews the process regularly. During work, it’s usually clear who’s doing what and how we work together. But with a team far away, with people I don’t see all day long, it’s harder to create a process and create clarity in who’s doing what.
There’re more variables that need alignment in distributed teams, but these four are what differentiates a distributed team from a collocated team in my experience.
I’ve made a first step in developing the method I’ve described above. But I’m not finished yet, as I believe it needs more depth. The method I developed is based on ‘The Bridge Canvas':
The building blocks of the canvas are the areas a distributed team needs to have alignment on. They must be discussed by the complete team, expectations must be clear between everyone and actions for improvement must be defined continuously. I have designed a workshop ‘structure your distributed team productively‘ to help teams with implementing this method. I usually do this in-house with a specific team. In one day, we discuss all the blocks and the team leaves with a clear collaboration plan and actions to implement right away. I also do it as a public workshop with people from different teams. In that case, it’s mostly about sharing best practices. I wrote about the results of my workshop ‘Best practices for distributed teams at Distributed agile in Berlin here. You can view more images of Bridge Canvas in action in the blog article.
For the method, I want to deepen each of the blocks with specific exercises, tools and frameworks. For culture, we’re developing a simulation now which we plan to call ‘survive the other culture’. In this simulation, teams go through video (exercises) to understand the culture of the other team members. Perceptions of the other culture are made explicit and discussed in the team. I am looking for 3 participants for the first workshop to develop this simulation. The participants could become co-founders for this product. If you’re interested, drop me a mail and I send you more information. For the communication block, we’ve developed another workshop to help virtual teams improve the way they communicate.
I am looking for people who want to join me in creating this method. Agile was invented by software development veterans and grew into a very large movement. Lean startup was invented by Eric Ries and his method is applied worldwide by startups and enterprises. The distributed bridge method (or whatever we’ll call it) can follow. If you’re interested, get in touch!
Read Next >> Do Cultural Differences Even Matter In Remote Teams?