Distributed Development: Collaboration (Part 1)

27 February 2015
| |
Reading time: 5 minutes

As the plane was setting down it marked a kick start of a tight schedule in the days to follow: non-pixelated live meetings with team members, meetings with the customer, pair programming and backlog refinement sessions, discussing business logic, and of course the evening fondue followed by a beer at the pub. Collaborating and watching a project progress is a satisfying thing, even if there are obstacles along the way.

Collaborating while distributed introduces a few of those obstacles by its own nature. Tooling and infrastructure issues, language boundaries, cultural differences, willingness of all team members to give their best to improve and constantly question their current setup. There are many tipps and tricks and also some important lessons our team members have learned in order to tackle these challenges.

This blog post will be published in two parts. In this one we focus on setup and infrastructure.

Setup and infrastructure

People who are not used to working in distributed setups often fear the overhead when setting up online meetings. This may seem true in the beginning, but the problem is easily solved with the appropriate setup. All team members (on-site and off-site) should take part in all team meetings, if possible. If you have several teams in the office involved in distributed projects, it becomes obvious that good scheduling of meeting rooms is essential. Plan your meeting schedules upfront and consider the availability of the facilities.

During the day there may be many informal meetings going on between both the on-site and off-site teams. It is not possible to find a free room at all times. If most of the people in the office are involved in distributed projects there can be several calls going on in one room – which significantly increases the noise level. In this situation a good headset with a noise-canceling microphone will enable you to work and collaborate from your desk. Although you can easily get used to joining all calls from your workstation, for team meetings like dailies, sprint planning, reviews and retrospectives you should always try to use a separate room.


It is well worth to invest in the infrastructure in the beginning of the project. A good conference microphone is essential for team meetings. It will save time and prevent from awkward moments when the team on the other side fails to understand what has been said. TV and a camera is a great idea for daily standups and will make the meeting feel more natural and relaxed. As mentioned before, if there are a lot of informal meetings between the on-site and off-site part of the team, or if access to meeting rooms is limited, then good headsets are mandatory.

The usual meeting setup consists of a big screen/projector, camera, conference microphone, speakers and docking station with mouse and keyboard. This equipment must be permanently installed in the meeting room. One person is hooking her/his laptop to the docking station, connects to the meeting and shares video and/or screen, depending on the meeting needs. On a screen we display what the other party shared – usually a video – so it feels like the whole team is in the same room.

Alternatively, you can use the preconfigured barebone PCs (connected directly to the TV and camera) which allows you to start the meetings almost instantly, without the need to adjust the settings or connect additional hardware. They come with severe limitations though, because they are often configured in a way which doesn’t support all the functionalities of modern computers (writing to disk, installing additional applications, using VPNs etc.).

Once you get used to setting up the meeting, it doesn’t take too much time and is usually done by one person. The others can join the meeting seconds before it starts.

It is important that the team defines the structure and the content of the meetings in a proper way. The team should decide who will be responsible for moderating certain types of meetings. This should be defined based on the context, e.g. if the requirements are defined on-site and the off-site part of the team is not completely involved in the process, then the on-site team member should moderate the estimation and sprint planning sessions. This will make the meetings a lot more efficient and easier to conduct.

A lot of information is often shared during the day when you have to immediately ask a question or discuss something with a remote team member. In situations when there are a lot of communication channels between the on-site and off-site part of the team communication overhead can easily become a problem. To minimize the overhead, you could share your idea with one of the remote peers (define a single point of contact), and that person can bring your idea to the rest of their collocated colleagues. If an additional discussion is required a formal meeting can be scheduled.

It is also important that all team members know key contact points for every part of the infrastructure (system admins, DB admins, network admins, external partners…). So everyone can solve infrastructure issues easily. A central documentation of these contacts in a wiki can be helpful as well.

In the second part of the post we will focus on the tools available for remote collaboration.

Comments (0)


Sign up for our Updates

Sign up now for our updates.

This field is required
This field is required
This field is required

I'm interested in:

Select at least one category
You were signed up successfully.

Receive regular updates from our blog


Or would you like to discuss a potential project with us? Contact us »