Successfully Coordinating Remote Dev Teams

If you work in software development long enough you’ll eventually work on a project big enough for more than one team, and some of those teams may be located in geographically-disparate locations (i.e. not in your home office). When this happens you’ll be exposed to the joys of having to coordinate these teams across space and time. This can be a daunting task, especially if your goals include maintaining a consistent development velocity for all teams and deploying on a regular basis.

I’ve found myself on multi-team projects more than once, and there are a number of steps teams can take to coordinate effectively, allowing the machinery of the project to keep moving. Most of these are common sense, but you’d be surprised how often they are overlooked. Lets take a look at some of them, shall we?

Communicate Face-to-Face

Face-to-face communication is one of those things that is easily taken for granted within a localized team. You see and speak with your team members on a daily basis, and you never really really think about what that means in terms of velocity until you have to go without this huge advantage. Communication really, really matters when you suddenly have to work with people who aren’t located in the team space.

That being said, the first rule of coordinating remote teams is to communicate face-to-face as much as possible. It eliminates a large amount of miscommunication and laggy, ping-pong email conversations as you can get to the point, ask questions and quickly get answers. You also get all the nuance of verbal and physical communication; there is a clarity of speech and body language that just cannot be achieved via e-mail or instant message. Finally, seeing your fellow remote members is a great reminder that there are actual people on the other side of those commit messages. It’s a lot harder to think in terms of “What are those idiots doing?!” when you can see and speak to them.

One way to achieve face-to-face communication is to have a dedicated machine with a mic, web camera and a large screen right in the team space. The team I’m currently on uses Google Hangout for the video chat as it is free and easy to use, but any video solution will work as long as you can keep the video up consistently. It’s important to make sure you have a solid internet connection and good audio/video equipment, as lag or distortion can dampen the effectiveness of the communication.

Decouple Teams As Much As Possible

Another major sticking point for remote team coordination is making them dependent on one another and expecting them to maintain a high velocity. The more dependencies a team has the slower it’s pace of delivery will be, therefore teams should try to emulate well designed software and be as decoupled as possible. They should be able to operate independently and autonomously to the degree that they can accomplish their goals (and the project goals) as they see fit within a set of constraints.

Break Up the Work

From the perspective planning and assignment of work this means giving each team their own backlog and swim lanes of user stories. If done right this can minimize dependencies and, hopefully, merge issues (assuming the codebase is relatively clean and modularized), while at the same time allowing teams to develop complete features.

Recognizing dependencies in the features and the codebase becomes very important when breaking the work out between teams in this way. Care should be taken to assign entire “slices” of work to each team, rather than forcing them to wait on the work of another team.

Maintain Separate Complexity Estimates and Velocities

Once teams have their own backlogs they should be allowed to come up with their own complexity estimates for user stories, and to break the stories up as they see fit in order to get the work done. This makes sense as it will be each team doing the work, and they will know best how complex a given piece of work will be given their own skillsets, experience and knowledge of the system.

It may be tempting to compare one team’s velocity to another at this level, but beware, adding apples to oranges together doesn’t give you fruit in this case, it gives you apples and oranges. A team’s complexity estimate for user stories are unique to that team for the reasons given above. Another team may look at the same piece of work and estimate it entirely differently.

Keep the Cadence, Separate the Team Practices

When coordinating releases across teams it becomes important to keep them on the same sprint cadence. Within the sprint however each team should be able to manage their own practices, including stand-up times, grooming sessions, sprint retros and commitments, and other non-dev practices. It’s important for the teams to be able to operate autonomously with as little coordination with other teams as possible, and these practices should remain the domain of each individual team.

Be Good World Citizens

Allowing remote teams to operate autonomously can be good for velocity, but there still needs to be certain amount of coordination. If possible, ambassadors from one team should attend the daily stand-up of another, and tech leads should meet as often as necessary to keep everyone on the same page. Similarly, planning should include members from each team, and ideally it should be in the same physical location, so a certain amount of travel might be required.

From a development stand being a good world citizen means being considerate of the developers on the other teams. Putting the build in a broken state and then leaving for the day doesn’t do the devs a few hours behind your timezone any favors. This kind of behavior should not be tolerated, as it can cause development for entire teams to come to a screeching halt while the cause for the broken build is investigated.

Think “We”, Not Us and Them

Finally, it’s important that teams remember that they are part of the larger project, and that being successful is more than just the team being successful. Coordination between teams in general can be difficult, and remote teams make it more so, and so the idea of “we” should be fostered as much as possible.

Did you enjoy this article? If so please recommend it, and check out my other articles . If you have any thoughts about this article I’d love to hear from you. You can find me on Twitter as @jameskbride. Thanks for reading!