Ok, so by now you should already know that, when compared to co-located teams, distributed teams sucks badly. That does not mean at all that you can’t have great distributed teams: it’s just way more difficult and hard to find. Communication, culture, identity, collaboration, trust, awareness and several other key factors for performance are affected when we can’t share the same space.
As I wrote in my previous article, if you can’t get rid of the noise (i.e., bringing your people back together), you have to increase the signal. You have to think on ways to increase al these performance factors remotely, and invest into them aggressively. I promised to give you some clues, tips and insights on how to deal with this, so here you are.
- We are a team: and not just any kind of team, but a problem-solving team. This is different, for instance, from a bowling team or a chess team, where every ‘team’ member will play their game and add their score to the ‘team’s’ result. In such a team, if results are bad but one team member won his games he might say ‘hey, it’s not my fault, I did my part’. This kind of behavior does not work well when we have a common problem to solve. Being a team means that decisions are made together, information is shared and we help each other to succeed. This needs to be enforced through the rest of these rules.
- Enforce communication: communication must be pushed, not pulled. Team members must not seek for communication only when they feel that it is important or needed, there must be something similar to the ‘osmotic communication’ that happens on a co-located team. For some distributed teams I’ve coached, it was usual to have not one but two daily meetings to synchronize and organize work.
- Enforce collaboration: the trend to work alone and isolated is bigger on distributed teams. Team agreements should encourage people to share work items and work together at them as a way to share knowledge and achieve a common understanding and way of working. Tools like a version control system, shared environments and continuous integration help teams to be aware of what everyone else is doing and force people to collaborate on a frequent basis. If you have people in two locations, making them team across locations instead of creating local teams will help to lower all the communication and collaboration barriers created by distance (see Jeff Sutherland’s notes on SirsiDynix case).
- Frequent delivery: risks on a distributed environment are greater. In order to find out problems as soon as possible, you want to make feedback loops as short and frequent as possible. For instance, you could consider asking for working software at the end of every week instead of every two weeks.
- Inspect and review: especially for outsourced teams, it’s not enough to have working software. Even running, tested features might hide spaghetti code, rat nests and technical debt that will make software maintenance or evolution a nightmare. Code must be inspected locally to be sure that the remote team members are following the relevant guidelines, code standards and best practices. You don’t have to read every line of code, but opening some files and ‘smelling’ the code daily is a very good practice. For distributed teams, each team member should take the daily task of inspecting someone else’s code for a while.
Bonus tip: you might want to check Luis Gonçalves’ article on how to build trust on distributed teams.
- Videoconference: nowadays, with ubiquitous and free videoconferencing tools like Skype or Google Hangout, there is no excuse not to incorporate videoconferencing as a regular mean of communication amongst team members. Planning sessions, retrospectives, demos and daily meetings work better if we can see each other while we discuss.
- Shared desktops: the ability to share a document and see what the other person is doing, or even being able to write, code or modify a file together makes it really easier to collaborate. Skype is a good tool for this, but there are others you might want to explore.
- Shared folders and repositories: a version system is a must for any software development team, Git /GitHub being one of the main players in this area. Google Drive, Gdocs, Dropbox and similar services have made sharing files something trivial, although your team might need some rules on how to modify these files without smashing other people’s changes.
- Same environments: you have to make sure that everyone is using development environments that are identical, meaning same versions of product development stack, database, etc. Using a shared environment for everyone is a controversial measure – it ensures that the environment is the same, but it might introduce more trouble if someone breaks it and might scale worse – like, for instance, if someone need to stop a service and then everyone else must wait. The shared environment approach can be substituted by frequent code chek-ins, frequent builds, frequent test runs and frequent deploys.
- Constant Chat: Videoconference is great for meetings, but you need a lightweight solution for constant communication. Chat and Messenger tools are the preferred approach for many teams, but I’ve had some success using Audio chats: all team members will log in to a common audio chat room and use headsets all the time they are at work. This favors all kind of informal communication to happen, all the time (like someone inadvertely saying ‘dammit, why is the server not responding?’). If someone needs to be concentrated and not interrupted, he might open a separate audio room with the title ‘do not disturb’, which still allows other team members to reach him by audio in case of an emergency. Ventrilo or Team Speak are a couple of tools I used in the past, you might want to try others. Very recently, the Happy Melly crew gave some enthusiastic reviews on Slack, you might also want to check that one.
- Project Management Tools: In case you need some project management and coordination software, Basecamp, Asana and Trello are very popular tools these days. If you can afford Jira + Confluence it’s also very recommended tool. I’ve also found that many teams will just need GitHub for coordination and project management. Anyway, review your actual need of these tools. I’ve found many times that a simple shared spreadsheet with the backlog and little more information is bare enough to coordinate most teams.
- Knowledge sharing: In his (recommended) book about managing a distributed team at WordPress, Scott Berkun describes how most teams at Automatt used a WordPress Blog with a specially customized theme (P2) as a repository of most team conversations, tasks, discussions… This makes it easier to search for past discussions, or even to leverage the learning curve of new team members. Wikis might also be a good tool, specially if you can link them to the project management / software development tools – check Confluence for this.
In my next articles about distributed teams, I’ll share some final thoughts on working across different time zones and cultures, as well as some rules for working solo at home. Stay tuned for them!