Distributed development: Q&A Session (Part 1)

1 June 2015
| |
Reading time: 6 minutes

In our previous posts we focused on the experiences, thoughts and challenges of distributed development mostly from the off-site perspective. As we all know there is always more than one side to every story. This is why we decided to ask our on-site colleagues to answer some questions and share some thoughts on distributed development.

This blog post is divided into Q&A sections which together represent a retrospective of our work in several distributed projects. We have highlighted the roles of the on-site team members to better understand the context of the answers.

What were the challenges?


Not having the client nailed on using English as project language from the beginning ended up in burning unnecessary time in the long term (for translating stories and alike). (Client insisted to use German language to a large extent…).

If the client (or any involved party) is not comfortable to directly communicate with the People abroad this might cause some unnecessary loss in productivity (also true the other way around…). The client has to realize that the distributed team members should be equally treated as the local members (probably more important for small teams..?).

There is not as much time gain in small distributed teams (shorter communication ways) compared to small collocated teams (no next desk effect).

Some clients may have restrictions in their IT security and tooling landscape that might make productive work harder (in the beginning). You most probably need to bend and challenge their IT a little bit in the beginning.

Bringing people to participate consequently in meetings like dailies and alike is probably harder than in collocated project set-ups. The barrier to skip an online meeting seems to be much lower than to skip collocated meetings.

Getting to know the colleagues from Belgrade. Also, infrastructure setup for daily and longer meetings, going from the physical board to a virtual one, finding suitable software for pair programming.

Building trust, establishing team processes and last but not least technological/infrastructural difficulties (still persist in a way).

Developing a roadmap for the introduction of the new team members, setting up the infrastructure to conduct distributed meetings, convincing the customer.

Team leads

Creating the possibilities for an open and proactive communication between people that are located in different cultures and do not see each other on a regular basis. In addition to this, transition from paper / white board based tooling to a completely digital tool chain caused some challenges.

You need to accept that distributed development brings more communication overhead.

Product owners

I felt some uncertainty in the team, because this was a heavy change to the team setup. So far we worked in a very collaborative and interactive way, with lots of one-to-one and ad-hoc communication. There have been doubts how this team culture could be established in a distributed team. I think that, apart from the obvious challenges in the infrastructure, the team culture topic was the major challenge. We remained true to ourselves and didn’t change our processes too much. We really wanted to establish the “one team” spirit across borders with an intense onboarding, co-located social events, responsibilities on both sides and tasks regardless of location, etc.


What did you like?


That after some effort the distributed setup can work pretty much as good as any other project – at least on the Zühlke side. (No surprise on that point).

Really great to work with colleagues from another country. Also the challenge of doing it in English. I loved the days when we were collocated as we always spent one or another evening together. Also the possibility to visit Belgrade.

Exchange trips, learning how distributed meetings & distributed work function, experiencing the “explorer spirit” in which the whole thing was conducted.

Team leads

The exchange (also the cultural) with people from a different country. To have people with a different view on a certain topic opens the room for interesting and valuable discussions.

Project managers

The international environment, to use my English, get to know another culture, be there from the start of distributed development and learn what the challenges were and how they were solved.

What did you learn?


You can learn new/different communication skills.

You can see new ways to look at things and to work on things.

“Managing”/working in distributed teams needs some time that you have to plan for beforehand. So that you are not consumed with these tasks and cannot do your real work.

You need some tools (e.g. for communication) that have to be enabled within the customer’s IT infrastructure.

When the colleagues from Belgrade started their work for the project, organization needed a bit more effort. I think it is really helpful to get to know each other as well as possible while the Serbian colleagues are in Switzerland (e.g. the first 2 weeks). It is much easier afterwards to just ring them up for anything you want to ask. All team members should be involved in “whatever happens” in workday life (I think hipchat works quite well).

DD does work in smaller teams better than in larger in my opinion (team spirit building with more people in the beginning was a bit harder). But then again, we did it now in a fairly small team.

It’s possible, becomes a more and more relevant topic in software development, infrastructure has to work really well in order to minimize the creation of islands (“hmm, should I set up online session XY or just call my colleague Z from the table next to me to do the Review?”). Social events are important to form trust and build a working, distributed team.

Team leads

Web cams are an important tool to enable the communication within a distributed team. The investment in a good communication infrastructure (headsets, conferencing tools etc.) pays off very quickly.

It’s all about people. If you have the right persons, then it doesn’t matter where they work in order to have a performing team.

Product owners

Drinking together is crucial too 🙂

Project managers

Tools that can be used for distributed development as well for other purposes.

What did you lack?

Team leads

For discussions around complex topics a white board is an important and efficient tool. Videoconferencing tools cannot replace this appropriately.

You can’t just go for a coffee break together and have some small talk.

Product owners

Having all the people in the same room, it is very easy to notice the overall mood in the team. The distributed setup lacks this.

What did you long for?

Team leads

A reliable and working collaboration solution where all involved persons (customer, on-site & off-site team) could easily communicate and work together.

Read about the remaining questions and answers in the second part of this post, coming soon.

Comments (1)


Janet Parker

13 November 2017 at 08:20

One guiding principle for me when writing Angular code is to focus on decoupled models. It gives you a clean design that is both units testable and reusable. Try to resist the temptation of doing direct DOM manipulation in link functions through jquery. Instead, try to solve the most problem via declarative data bindings against decoupled models: I have an example of what I am talking about here: Decoupled object models in JavaScript. Read more here, https://viitorcloud.com/hire-angularjs-developer


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 »