Remote software team - setting up the collaboration

Remote software teams is way forward in software development. No longer are companies tied to particular locations, waiting for resources and skills to be available and delaying the entire software process. By finding the right software resource at the right time and forming a remote team to work with any onsite team completely changes the game - and companies that are realizing this are getting ahead in the game. This is just one more evolutionary step in our ever changing industry, a step that has just been accelerated by COVID but it was a step that was bound to happen at some time or other.

As with any paradigm shifts such remote software teams come with some adjustments in work practices and process. We’ve been working with hundreds of companies around the world for the past 18 years in providing software resources and hosting such remote software teams. Here are some our tips about the right setup for collaboration and workflow for such remote teams.

Setup a clearly defined work process

This may sound obvious but you’d be surprised by how many teams we’ve come across that just assumed things about the work process for collaboration of remote and onsite teams. This is understandable though, when a team works side by side many of the work processes are automatically defined and agreed upon without explicitly defining them. An example would be the timing a push of latest code into the shared repository - if the team is all together very soon a standard of when a push is appropriate and acceptable is agreed upon. A few wrong moves by a new team member quickly gets fixed by visual (and sometimes very audible!) ques from the rest of the team. But now imaging when part of the team is spread out remotely. The same mechanisms of automatic agreement doesn’t happen fast and sometime never. There is no way out on this, for teams with remote members the lead has to layout a clear set of instructions for major work processes. What the major elements are depend on the nature of the project and the team members but here are some that are obvious candidates:

Work timing - when to be available, when are good times for pinging without advance notice, when not to poke, etc.

Tools - defined set of tools for collaboration like issue tracker, IDE (specially versions of IDE)

Reporting standard - when to cry for help, when to warn about delays, what to report and what not to worry too much about, etc.

Testing rules - what should be the minimum set of tests on the developer’s side (even if unit testing frameworks are available for the CI/CD), etc.

Code repository rules - when to push, who can merge, etc.

Meeting rules - what tools to use, what are the good times for combined calls, how long the meetings should be, etc.

Create an open communications channel

With team members spread out geographically the open communications channel is essential for a healthy team dynamics. One common strategy is to have video call regularly with the video on (visual is very important forming the bond between team members). An awareness withing the onsite team about keeping the remote team members in the loop on all important decision making process is absolutely essential. Running regular video meetings is one of the best way to avoid issues caused by communication gaps and it has the added benefit of making the remote team members feeling valued. These video meets should ideally to be planned in advance and hosted at a time that works for everyone. A random last minute email to setup these calls isn’t the way to do it. Formalize at least a regular video meet by setting up a recurring invite so that everyone are reminded before each session.

Regular team calls should have the goal of keeping remote team members updated and also getting feedback. Remote teams should not find out about important decisions at the last minute. This has huge impact in lowering morale within the team members and would start creating a divide between the onsite and remote staff. If there is a new process change or some important company news a specially rededicated call aimed at all the members should be placed to keep everyone on the same page.

Use team collaboration tools as much as possible

For onsite only teams we always push for face to face informal interactions more than a very process and tool centric interaction. This is completely the reverse when the teams are spread out. In such teams you should aim to have all major collaboration purely tool driven. A good example would be work distribution on a issue tracker. For onsite only teams it’s usually great to have a quick ad hoc meeting to split a task and then asking team members to just create and assign the tasks to themselves - it moves the needle move faster and just feels less clunky, less “bureaucratic”. But doing this for remote teams is recipe for disaster. It’s best to rely on the tools, have as much as possible of the discussion on the tools (e.g. a discussion thread on the issue tracker, or slack, etc.).

It can be difficult to keep track of the progress and monitor the status of the project at every stage for remote teams. Using a great project management tool like Atlassian Jira is essential. Such a tool must have features for creating tasks and subtasks, assigning them to team members, tracking the task and setting time estimates for those tasks, etc. Such a system should also have a way for discussing details of task, a way to collaborate at the task level with a log of what is going on. Here’s a screenshot with an example of an ideal task ticket tool feature.