Making Distributed Teams Work - Before you start...

Introduction

This is the first article in a series offering pointers on how to make the most out of a distributed team. The series is based on experience with growing internal teams with additional near shored developers rather than building a completely external team. It is my experience that completely external teams don’t work as well as distributed teams.

The first article (this one!) will cover things to put into place before you start to grow the team. It will briefly describe what you should put into place before you start to engage with external suppliers and why. Later articles will cover topics such as hiring practises and how to keep the team working as a single, unified team.

Team DNA

Before you grow your internal team with near shored developers you should ensure that the team's DNA is in a healthy state. The near shored team will pick up the mood of the local members of the team and mirror that. If your current team is struggling then you can expect the same as you grow it.

As such it is vital you first get your own house in order. Hopefully nothing in this section is new to you as it covers best practices.

Love the CI server

At the absolute minimum you should have a CI server building the project and running any automated tests. Failures on the CI server should be handled before new functionality is developed. Absolutely no one pushes onto a broken build and build broken for more than X minutes is reverted.

Without this in place before you start you can find your local team (who are used to “shouting out” issues) tripping over the feet of the near shored team.

Clear Branching Strategy

It does not matter which strategy you use (I’ve seen toggles with virtually no branching work well with the right team), but the local members of your team should love it, be willing and able to evangelise it and most importantly of all quickly and clearly explain it. If you can’t do that the two teams will start to move in their own directions leading to a lost of time and effort rehashing old arguments.

Pairing

This could be simply pair merging-to-master or full pair programming. This becomes more important when you onboard new developers as you want the new members of the team to follow (and extend) your ideas on quality. It also allows you to ensure that the quality of code remains consistently good.

Waiting until you onboard the new members of your team before starting pairing will make the initial pairing exercises awkward as the local members of the team will not be used to doing it and the pairing exercises will be infrequent again as the local members of the team will not be insisting on it allowing code not to the quality you would expect to sneak in.

Little A agile

This is not a slam on big A agile - by all means be that too. Expect everything you set up before bringing in the near shored team members to change as you work out what works for your team. The team will start off broken and will need time and willingness to fix it, so ensure ahead of time that the local members of your team are open to new ideas.

Little A agile as a scheduled retrospect may not make sense in a very small team of a couple of co-located people, but is vital once the team grows and are no longer co-located.

Enable Work From Home

Some members of your team will be effectively working from home most of the time. Making this as seamless and easy a process before bringing them on board will mean that the relationship will start of a high note.

While VPNs can allow the remote members of your team to work as if they were in the office the reality is it will be a good chunk slower. So some practises you can use in for an office based development team (like utilizing a single central development database) don’t work when you have a slow connection to that database. So either use an completely dev-local, in-memory database during development (Derby or the like) or use something like Vagrant to build up a database.

Think about how you store and access your source control. A local hosted repository works great when external access is rare, but when it is the norm your need to make sure your VPN is bullet proof or move it out of your network.

How easy is it to set up a virgin machine? At the bare minimum ensure that the steps are well documented, ideally completely automated. Either via a virtual machine that anyone can just spin up and go with or utilizing a scripting platform to build up a computer to a known state.

In Summary

If you have a healthy team to begin with then expanding them with near shored members with be a lot more likely to succeed. However if the local team needs some work then you have a sizable project to do before you start. While you could prioritize hiring at the external company to bring in experts to help set this up you risk building an “us-vs-them” atmosphere within the local team and for a distributed team to work the team must gell. So try to solve the problems locally by either training or bringing in a local expert.

This article was originally posted on LinkedIn Pulse.