Distributed Teams – It’s a Balancing Act

For the past almost 2 years I’ve been working on a distributed development team with members located in both London and Delhi. We have the typical communication, time zone and cultural challenges that all distributed teams face but I’d like to discuss something I’ve noticed about our team which its structure.

The following is a very simplified flow of how a piece of work (a story if you like) moves through the roles in the team.

Typically a business analyst (BA) will talk to the business and gather requirements and write a story. This story is then coded by a developer who when done passes it to a quality assurance person (QA) for testing.

There is nothing special here and naturally there are other roles on the team such as project managers, operations people, DBAs…etc. but in order to keep this discussion simple I’m choosing to focus only on the BA, developer and QA roles.

If you look at these roles across the team as a whole the balance seems about right. We have the right numbers of people in each role and there is a good mix of youth, experience, business and technical knowledge.

However when each region is taken in isolation this is not the case and this can cause problems.

Role Imbalance
The first imbalance we see is the number of people filling each role in each region. This is most evident in the business analyst role as most BAs are located in London.

The reason for this is that the project’s customers are located in London so it made sense to have the majority of BAs close to them. However this means is that the developers in India have less direct access to the business analysts.

As a developer I find that regardless of how well the stories have been written nothing is better than discussing a story directly with the BA. The developers in the team in India have a distinct disadvantage, sure they can contact the BA by phone or instant messenger but they have language and time zone issues to deal with. The result of this is that at times the developers are forced to make a ‘best guess’ at what a requirement in a story means.

Skill and Experience Imbalance
The second imbalance between regions is not related to the number filling each role but the level of experience and skill in each location. This is most noticeable among the developers on the team.

If you look at the number of developers in each location they are about the same, however on average the developers in London are much more experienced than their counterpart in Delhi. This is in both the sheer number of years spent writing code as well as the skills specifically required by the team such as test driven development (TDD), agile practices, general software design and the specific technologies being used.

The effect of this is that the code quality has suffered, technical debt has increased and more bugs have been produced. This is not an attack on the Indian developers but the experience mix of the team. Any junior team working in isolation would have similar issues.

Attempts have been made to resolve this problem by swapping developers between locations for short periods (around two weeks) so that skills can be shared. Also attempts were made to do remote pair programming sessions and code reviews via phone and remote desktop but these failed to have much long tern effect and were discontinued. The developer exchange was the most helpful but it was still not as productive as having all of the developers permanently collocated.

If the team were located together the experience imbalance would be less of an issue, as the junior developers would have the more experienced developers to advise them and ensure that good practises are being maintained.

Activity Imbalance
The final imbalance between the regions relates to testing. Unlike the other roles, the number of QAs in each region and their experience levels they have are very similar. The problem we have is that the testing activities being performed in each region are not the same.

Our team performs two distinct types of testing.

  • Testing that is done when a story is completed by a developer that tests that story’s specific requirements, and
  • End-to-end testing done after the system is deployed to an environment similar to that found in production.

These two types of testing are not shared equally between locations. Story level testing is more frequently done in India while the end-to-end testing is generally done in London.

It is important for the QAs to have easy access to the developer who has just finished a story so they assist them in diagnosing any problems and it also allows the developer to get feedback on what they have just completed. This should preferably take place while the story is fresh in the developers mind and not moved to the next piece of work as continual context switching is demanding.

Often from a London developer’s perspective it feels like story’s are ‘thrown over the wall’ to the QAs in Delhi and there is then not much feedback on its success or failure. This seems to be less of a problem in India where the QAs and developers are close to each other and can work together.

The outcome of this is that the London developers often don’t find out about issues until weeks later (possibly during end-to-end testing) by when they have moved onto other stories.

So what we see is that while the overall structure of the team appears fine the problem is that in each location the team has deficiencies that cause it issues. Redrawing the story flow for each location it probably looks more like this:

In London there is a strong link between BAs and devs due to their easy availability but a weak link to QAs because it is most likely that the tester for their story is located in India.

Conversely in Delhi there is a weak link between BAs and developers as most BAs are located in London but a strong link to QAs as the tester for their story is probably a few desks away.

Also shown is the weak link between the experienced developers in London and their junior counterparts in India.

For a team to be productive communication between BA, developers and QAs is very important and they should be able to take place quickly.

A BA should be able to discuss the story directly with a developer in the same location to ensure the requirements are correctly understood. Similarly a QA should be able to test a story reasonably quickly after it has been coded and talk directly to the developer who worked on it to help diagnose bugs. For distributed teams this type of communication is difficult to achieve.

What we see on my team is that while the team as a whole seems balanced, in each separate location they are not.

The teams in each location need to be able to function independently of each other to complete a story without continually communicating to the remote location.

One suggestion that has been made is to break the team into silos (or function teams) where X is done in London and Y is done in Delhi. This however makes the team inflexible to changing requirements. You could end up with the situation where a certain part of the system becomes more important but it can only be done in Delhi while the London team sits idle. Knowledge of the system and the workload should be shared across all locations.

The vision should be to have two independent teams that are fully functional in their own right but in different locations, working on the same project sharing work evenly. This also reduces the communication problems, as one location is less reliant on the other for a particular piece of work.


One thought on “Distributed Teams – It’s a Balancing Act

Comments are closed.