Distributed Teams or Co-located Teams in Agile

Which is more effective, a distributed team or a co-located one? I am not convinced that a co-located team is more effective. I don’t care how many times you say it, I need more proof than the one study I could find that supported it, but also made a chart about how the team felt the noise in a co-located team negatively impacted their effectiveness.

I have covered it before and I have provided some sources in those posts that pretty much argued that people located in one room together usually have issues. The individuals usually don’t like it much, citing privacy and noise issues. There are cases of socialization ruining productivity (An Examination of Team Effectiveness in Distributed and Co-located Engineering Teams).

Some have reported that the teams will begin instant messaging with each other to avoid creating more noise once they are subjected to an open office type environment (Open Offices Suck) I can do that at home. The only real difference between a co-located team and an open office environment is the number of people in the room and the number of teams; admittedly the problem is worse in a purely open office environment.

Distributed TeamsI have argued that the increase in technology since the creation of the nearly 20-year old Agile Manifesto has made the process of being distributed much more effective (Face-2-Face Communication May Not Be Needed). The Agile Manifesto that made the claim lives in a world of dial-up Internet and 20-minute Napster downloads.

I have also argued that just about the only benefit that can be found is actually a flaw (Osmotic Communication is a Symptom of a Flawed Process). It is a flaw, you shouldn’t have to rely on accidentally overhearing someone for needed information. Improve your communication process instead.

I have covered the problems with telecommuting (5 Challenges of Telecommuting) and I have discussed how to make it better (Distributed Agile Teams and the Telecommuting Naysayers). I even pointed out the blunt hypocrisy of software developers not willing to use their own products to make their jobs easier (Hypocritical Situation of Low-Tech Solutions in Agile). It is un-Agile to be so concerned with the process and tools that you dictate which process and tools you should be using without first learning something about the people involved.

I don’t believe co-location is better. I don’t even like co-location. I hate it and I know from my personal experience that I perform worse in it.  I would rather sit in a cubicle.

I think Martin Fowler has some good points here in his quote:

Although I widely hear that a given team is more effective when co-located, a single-site puts a big constraint on who you can have in your team. Such a rule means you aren’t able to hire the best person for the job, you can merely hire the best person who is prepared to relocate. By making a team remote, you can widen your range of people you can bring to the team. A remote team may be less productive than that same team if it were co-located, but may still be more productive than the best co-located team you can form. – Martin Fowler

Although, I think there is more to it than that. Especially when you factor in time spent commuting, personal lives, noise in a co-located team, and there is no need for constant communication while doing individual work (People work better when comfortable).

Then there is team dynamics and conflict – personal conflict tends to be less of an issue in distributed teams. I wonder if anyone has written a “#metoo” on a distributed coworking peer? I suppose it has/could happen, but the threat seems minimized.

I did work on a distributed team once where you could tell this Network Engineer hated one of the guys on a different team. They had never met in person, which was interesting – and I can kind of relate as that guy was a bit too much too deal with even in virtual meetings for 20-30 minutes at a time. He was a know it all and I was thankful I didn’t have to work with him in person. It would have hindered our effectiveness if the Network Engineer had to work with him in a co-located team or even in person.

My underlying point, don’t choose a co-located team only because of the emphasis placed on it in the Agile Manifesto or Scrum.  That is placing the focus on processes and tools, and perhaps limiting some of your choices. You also shouldn’t choose a distributed team if you aren’t already committed to working hard on collaboration. A distributed team will bring out the flaws in your current laid-back communication methods that overly rely on Accidental Information Exchange. If you aren’t proactive about communication, It will show in a distributed team.

I strongly believe, and I think the evidence backs me up, that if undertaken correctly and proactively, a distributed team can outperform a co-located one.



Fowler, Martin (2015). Remote vs. Co-Located Work. Retrieved From

Yang, Maria C. (n.d.) An Examination of Team Effectiveness in Distributed and
Co-located Engineering Teams. Retrieved From

2 replies »

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.