≡ Menu

Distributed Agile: the black box of co-located team

First, a bit of the context: we are working on a project helping distributed Agile teams to identify challenges they have to deal with and to find solutions for them. Also, as much as I would like to make it a proper research project (with in-depth state-of-the-art review, large scale data collection and time to process all that), it is more of a research-based consulting: we observe a bit, interview some people, scratch the surface of what had been said on it and hope that our research backgrounds would help to fill in the gaps to come back with useful insights.

Second, a disclaimer: I’m not an expert on Agile software development, but have been learning about it in the past few months. And, while my research is pretty much about technology-mediated ways of working, research on distributed teams is not at the core of it. But all that shouldn’t prevent me from writing about it, isn’t it?

Now to the point. I’ll start from the values behind the Agile approach, as articulated in Manifesto for Agile Software Development:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Those values are supported by a set of principles and a variety of methods and practices that address those principles in practice. Now the part that is directly relevant to our case: while it’s not always immediately obvious, Agile methods are designed for a co-located team, articulated in one of the principles:

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

From one side, this makes the whole exercise of figuring out how Agile can work in a distributed team pretty pointless: it’s not designed for it. From another, there are various reasons for distributed Agile teams and examples where they work (some links). So the question is not if distributed Agile is possible, but how to make it work.

For me it translates into the focus on understanding what is actually happening face-to-face and then figuring out what of it and how exactly can be supported in a distributed settings.

Distributed Agile This is a simplified picture of what we have observed in our case. It is heavily based on Scrum as a main method, which could be described in terms of roles, ceremonies and artifacts. In a sense those are the known ingredients for the success, so a lot of effort goes into figuring out how they can work when the team is distributed. This involves, for example, finding tools and adjusting processes to support ceremonies (e.g. daily stand-up meetings) and figuring out how to share and update artifacts online.

However, next to those known ingredients there is a big black box: co-located team. Co-location and face-to-face interaction is one of the cornerstones of Agile, but from what I’ve seen there is not that much understanding of what exactly happens there. Which is fine when the team is co-located – we have evolved to make the best uses of face-to-face and don’t even have to think of what and how we do. But when the team gets distributed that lack of attention to the black box results in all kinds of challenges. And, given that Agile philosophy places so much value on informality, putting efforts into articulating and formalising the blackbox ingredients doesn’t get much momentum.

So, this is more or less what we are doing in the project: bringing research instruments to open the black box and then working together with the teams to figure out how to make it work in distributed settings.

[As you have probably guessed two previous posts are directly related to this one: Why sharing a team room might be not so good and What a coffee corner provides, how to call it and a research agenda. More to come :)]

Update – don’t be surprised that I’m adding follow-up posts when they appear:

{ 11 comments… add one }
  • Joshua Wold December 2, 2009, 22:23

    Interesting post. Atlassian (where I work) sells Agile dev tools very, very commonly used for dispersed teams (as we are). Agile by nature has to be quite social with pair programming, quick iterations digesting user feedback, etc so you are right about the co-location being at the heart. However in the same way that wikis and blogs have opened up org’s general collaboration, I think toolsets out there (such as ours) can open up Agile dev collaboration across borders.

    It would be interesting to hear some more follow-up thoughts from you after you’ve done some more research.

  • Pierluigi Pugliese December 3, 2009, 22:58


    Thanks for your post and your interest in researching on this subject: there is still a lot of work to do about agile and dispersed team.

    I have to disagree when you say agile was not designed for dispersed team: the principle you mention about face to face being the most effective way of communicating is, in fact, true in all kind of teamwork. The agile movement has simply started to openly talk about the issue – I saw many companies outsourcing their development trading resources offshore one to one without even thinking that there might be a communication penalty involved!

    In traditional project management a lot of emphasis is put on documentation as a way to communicate. Some process models like the German V-Model even define interfaces in terms of documents. But in fact, what they are doing in this way is to enforce a low-bandwidth common denominator for the communication which is still more inefficient than a quick phone conversation augmented by a short email summary.

    The agile community has spotted the issue and is also trying to solve it through technologies partially already exploited in open source projects. There are a lot of collaboration tools widely used in agile project that address the problem of documenting casual communication (IM, electronic whiteboards, electronic Kanban boards, in-the-code documentation), making disperse teams possible (and an actual reality in several companies), though still suboptimal compared to co-located ones.

    On the top of that, if agile is implemented properly – i.e. as an adaptive system through an efficient double-loop learning, for example via retrospective and coaching – communication bottleneck will be identified and addressed. If the adaptation of the process involves a more formal interface through documents, well, let be it!

    Be aware there is quite some discussion in the community about the meaning of the “overs” of the manifesto. The summary is that “over” could be read as “is to be improved with higher priority than”.

    I’m eager to read your next posts about this!


  • Lilia Efimova December 4, 2009, 01:09

    Joshua, Pierluigi, thanks for the comments! The point that I tried to make with “designed for a co-located team” is more about lack of articulation of what exactly happens in a shared space (because it just works and you don’t really have to talk about it unless it disappeares 🙂 As for the tools – I am with you here – there is a growing number of tools that can help with different aspects usually happening in face-to-face settings, but we need more insight into how they actually work to match them with what Agile teams might need.

    Joshua, do you have any pointers to what are the good practices of using wikis in Agile teams? Would love to read more on it.

    Pierluigi, re: double-loop learning – helping teams to understand better where communication doesn’t work and what to do about it is definitely part of our project. In any case, I tend to view research as “holding a mirror” that allows people we work with see their practices in a new light and to improve them.

    [Still not done with a presentation on the whole thing for tomorrow, so unfortunately blogging about it will have to wait a little bit.]

  • Barry Camson December 4, 2009, 18:33

    Lilia, I am currently reading a case study that I think will be informative with regard to your questions regarding Agile and distributed teams. It appeared in MIS Quarterly, Vol 25, No 2, June 2001. It is entitled: “Radical Innovation Without Collocation: A Cast Study at Boeing-Rocketdyne” Authors are: Arvind Malhotra, Ann Majchrzak, Robert Carman, Vern Lott. Your materials on Agile are very interesting. By the way, Socialtext uses Agile development approaches. Barry

  • Joshua Wold December 5, 2009, 03:58

    @Lilia – you might be interested in a blog series some of devs are writing on Agile. We’re a distributed (Syd, SF, Poland) Agile shop making Agile tools and so when our devs talk about how they use Agile, they share experiences related to how they do Agile as distributed teams.


  • Tim Ottinger May 24, 2011, 22:06

    There are some quick helps here: http://agileinaflash.blogspot.com/2011/04/rules-for-distributed-teams.html which may be more brief than you wanted.

Leave a Comment

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