A practical reality for many software development teams is that the people on those teams are not all co-located. This can bring many benefits, both for employees – avoiding long commutes or disruptive re-location, and for employers – who don’t need to expand or reduce office locations in response to fluctuating regional demands. Of course the Agile Manifesto had this to say on the matter:
“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
And some have taken this to mean that co-location of a team is essential if you want to be Agile. However, research actually suggests that distributed teams (in the same time-zone) are actually more productive than those located in one office together.
My experiences
For a number of years, I have been managing an Agile team of about 35 people distributed across 3 UK locations. My own experiences lead me to say that yes, you can be Agile with a distributed team. I would suggest that the key to success is to create a ‘one team’ ethos across all the locations. To do this I think there are two key areas that require attention: your approach to communication and your approach to managing the work.
Communication
Let’s start with communication. In line with the spirit of the Agile Manifesto (but noting that technology has moved on quite a bit since 2001!) I encourage my team to always try and use the most immediate form of communication possible. Sometimes this can mean face-to-face. But if that’s not possible then, in rough order of priority, video conferencing, phone, instant messaging and our workflow tool (JIRA). The more immediate the communication is, the faster the feedback loop. We aim to reduce misunderstandings and to correct any that do occur. I’ve also found that people who have met face-to-face at least once find it easier to communicate effectively via other means. With that in mind I encourage people to visit the other locations so that they don’t feel like they are instant messaging a stranger!
Managing work
Now let’s talk about how we manage the work. We use Kanban, and one of the core practices of Kanban is visualising the work. We do this with physical whiteboards at each location which are mirrored from a master version in JIRA. And this is an important point: to get the ‘one team’ ethos, the whiteboard in each location has to show ALL the work in progress, not just the items being worked on by people in that specific location. Although there is some overhead to this approach, I have found that having the full picture up on the wall where everyone can see it, creates a strong sense of unity across the sites.
Kanban also operates as a ‘pull system’, which means that as people on the team complete work, they can self-select what to work on next based on the team’s priorities. This means that I do not have to micro-manage individual task assignments. In turn, this makes it possible to keep the team structure flat (even with 35 people on the team). And whilst we have daily stand-ups around the whiteboards locally at each site, we have a weekly whole-team stand-up that is conducted via video conference. The whole team stand-up has an additional focus on reinforcing the ‘one team’ mentality (like sharing successes, kicking off new features, welcoming new team members, cross-team demos).
It can, and does work
These experiences have taught me that creating a team is not at all about putting people into the same physical space; it’s about getting them into the same head space. If you’re lucky, the first will lead to the second, but it is by no means guaranteed. What you really need is good communication in order to build a strong alignment. The whole team need to have a single understanding of the team’s purpose and priorities. And that applies whether people are in the same office, in different cities or even in different countries spread throughout the world.
