Working from elsewhere

Agile prescriptions, such as Scrum, keep preaching for co-located, strong teams that share a room and take on new work as the world around them changes.

I have stopped believing in this. As the world around us changes, we need to adapt. Strong co-located teams are part of an old paradigm that no longer is true. The reality has changed, and it is time we face it and adapt.

1. Teams are a constant. I used to believe in this, but after years of experience I can see that it does not work that way in practice. More about this in another post.

2. Teams have to sit together to create the best work. Reality does not always make this possible. This is what I explore below.

Why bother

After moving to Copenhagen I started working a lot from home to save myself the long commute. Changing roles I also started working more with people in the U.S. and Canada. This is giving me first hand experience of working remote and the pains and possibilities it brings. In the years I have been working at Qlik, R&D has gone from being (almost) co-located to having teams in six countries and four time zones, with a few people working from their homes. I think this is a reality for many software companies. With the work we do it is simply impossible to guarantee a team will share a room. Instead of fighting it I believe we should become better at dealing with work across locations.

People are becoming more flexible with their software work. Companies that can adapt to this will benefit hugely. Suddenly you can recruit across the world, and you might not have to worry about setting up an office in every location.

What if fit for culture and company values were the primary reasons for recruitment, rather than geographical location?

Mental closeness

It is not about geographical closeness, it is about mental closeness.

I love this quote by Jim McCarty because it beautifully describes that there are other things more important to a team than sitting in the same room.

When doing software work in the connected world the biggest blocker for great teamwork is no longer location. I have seen teams fail, even if they were sharing a room and had their product owner within arms length. I have seen teams succeed even though none of them ever met physically. For both these cases, co-location was not the number one issue, by far. Being distributed exposes issues that are already there.

More important than shared location is a shared goal, a shared language and a shared plan for how to reach the goal.

Shared goal

A group of people working towards the same goal is the definition of a team, whether they are in the same office or not.

Shared language

This is something a team builds up over time, or are bootstrapped with (for example by using the Core protocols). Listen for expressions that are specific to the team, that builds on shared experiences.

Shared plan

Every team member must understand how we are going to reach the goal, and what their individual contribution is. Work being done must be transparent to everyone in the team. Mistakes, learning and changes to the plan transparent so that team members can help each other and move forward together.

I think the best examples of distributed teams are successful open source projects like Linux, Apache and a wide variety of projects on GitHub. When people are intrinsically motivated to reach a goal (which is often the case for open source projects) and share a language (read some of the commentaries in the bug reports on open source projects) magic can happen.

There are also companies like Remember The Milk that don’t have an office but still create a valuable product that they sell to the world.

Flexibility and discipline

Each team is as unique as the individuals in it. Making distributed work possible will depend on the flexibility and discipline of each team member. Working across timezones makes a 9–5 schedule hard. Some meetings will happen outside of normal work hours. The discipline of each team member is equally important. When a team is distributed, lack in discipline becomes painstakingly obvious. Working co-located is much more forgiving as you can make up for failures. Working distributed requires a lot more discipline to make sure we keep the team going forward and are transparent, even though it might not always feel natural.

For leaders it will be important to trust team members and give them the ability to be flexible and disciplined. Allow people to work when it fits them and when the team needs it. Help people keep their discipline by supporting them with tools and modelling behavior.

Tools

The discussion about distributed work quickly ends up in a discussion about tools and processes. This was the case in many talks about distributed agile a few years ago. I think this is the wrong approach. Tools will help us address needs. We should still be focused on the problem, not the tool. The right tool will enable transformation and allow us to achieve more.

There is a myriad of tools, and without the toolbox we would not be able to work as we do today (just as a carpenter would not be able to build something sturdy without his tools). We use Slack, RealtimeBoard, GitHub, Jira and Confluence, paired with a few more. These tools are key, whether the team is distributed or not. The details of how we use these tools is a topic for another post.

No excuses

Distribution of work has been falsely blamed for bad teamwork for too long. I believe it is time to face the fact that teams will have to work distributed, and stop using it as an excuse. We have the knowledge, tools and working environments to do great work across locations. I think this is an interesting topic to explore so I look forward to your feedback, hear about your experiences and intend to write more posts on the topic.