Distributed Agile: communication and common ground

by Lilia Efimova on 29 January 2010

With the holidays I somewhat took a break from blogging on our work on the distributed Agile case, but there are still quite a few things there that I wanted to share to hear what do you think. This one is a bit scary since I picked up some ideas from linguistics without having a proper reading of the work behind it, but at times this is the price to pay* for sitting between research and practice.

Communication and common groundSo, the picture on the right is a simplified version of the work of Herbert H. Clark:

According to Clark, in order for one person to understand another, there must be a “common ground” of knowledge between them. He shows how people infer this “common ground” from their past conversations, their immediate surroundings, and their shared cultural background. [This is from a back of Clark’s book “Arenas of language use”]

In my terms: communication is enabled by the common ground between the participants and, in turn, contributes to building more common ground over time. Taking it a bit further, it is useful to distinguish between two components of the common ground:

  • information that the participants share (not necessarily explicitly, as it is often assumed that others know about X because of shared cultural, educational or work background) – I talk about shared knowledge and awareness of the bigger picture here
  • relationships between the participants – knowledge about each other and trust

Now to the distributed Agile teams. At a starting point there is a big distance between the team members:

  • different locations that make it difficult to rely on team-building and ad-hoc interaction that naturally happens in a co-located team;
  • time differences that in some cases provide only a small window of opportunity for interactions;
  • different cultures, organisations and levels of technical expertise create difficulties of getting a team “on one page” needed for seamless work.

Communication and common groundDistance between team members across different locations creates a vicious circle:

  • lack of common ground, the need for using technology and addressing time issues make communication challenging
  • challenges in communication make it difficult to overcome initial differences between teams, to build relationships and shared understanding of the bigger picture behind work

This picture is not that far from what you can learn by reading about the challenges of distributed Agile and solutions to address them, but hopefully it can help to address the problems in a more systematic way: spending time on establishing shared understanding and relationships in the team (especially in the beginning) and finding ways to shape communication processes and tools that not only allow to get things done, but also contribute to growing awareness and relationships over time.

My personal “hobby horse” is around the last point. From what we have seen, the communication in distributed teams often shrinks to purely functional and, compared to face-to-face settings, there is much less unstructured informal interactions – this works for getting the work done (at some level), but seriously limits the opportunities to build awareness of the bigger picture and relationships. Most of the solutions in respect to building the common ground in distributed Agile teams still rely on making sure that there are opportunities to visit each other, while there is a lot of space for a technology-mediated ways to do so next to the f2f.

* The ideas behind this post are grounded in insights coming from research on computer-mediated communication and distributed teams, but I need more time to read papers and to integrate research ideas in a systematic way. Hope to blog about it soon.

{ 1 trackback }

Harold Jarche » Building common ground
29 January 2010 at 15:38

{ 2 comments… read them below or add one }

1 Gregory R. Lloyd 29 January 2010 at 19:09

And excellent post and fascinating project, thank you and please continue work on this topic! I believe it’s a valuable contribution to understanding Agile as well as broader Enterprise 2.0 use.

A few questions (please leave a link if you already covered these topics)

1) In your case study and research what media do you include? Members of our team use: Traction TeamPage (integrated weblog, wiki, liveblog, email digest and email/jabber notification, activity stream, rss feed); iChat video + audio + jabber; Mercurial for source code. Full disclosure: Our team is Traction Software and we’ve historically bootstrapped all of our own engineering and other work using our own product.

2) Team members get together face to face on an irregular basis (visits or meetings) which generally have a broad topical purpose, but lots of uncommitted time for discussion and socializing (we all like good food!). What patterns of face to face meetings do you see?

3) Always on iChat audio video and liveblog + jabber + email notification don’t replace F2F but seem to be very successful in balancing folk’s ability to

a) Work without distraction – politely defer a non-urgent question or discussion

b) See what’s going on (livebloging status and requesting time for a non-urgent follow on question or discussion)

c) Ask a relatively urgent question (Jabber)

d) Open a Video or jabber chat.

The social norm seems to be a general acceptance of a polite request to defer or set a time for a question or discussion, often using the shared liveblog space so that all other folk are aware of this discussion and can join in later, offer help, etc.

4) I find that different folk have different preferences for doing a tatus scan and getting notifications, for example:

I prefer RSS feeds from all internal TeamPage and external sources (about 400) refreshing every two hours + an always on liveblog window for awareness.

Others prefer to get email digests of all activity + email notifications on new items or conversations of interest + a liveblog window

Others prefer an activity view of all new / edit / tag / moderation TeamPage actions for summary on demand + a liveblog window.

Mercurial source code checking notices are posted to a TeamPage space and are reflected in the rss feed, notifications, or activity view. A shared liveblog window seems to be the common channel for coordination and response using other media.

2 Lilia Efimova 29 January 2010 at 20:14

Gregory, thanks for the questions and sharing your experiences! As for the answers: not sure how much I can tell in public, so sorry for being a bit vague.

The teams we worked with are relatively new to Agile and the distributed version of it, so there is a huge potential for using a variety of media and a lot of experimentation with various tools (it was hard to get an overview since teams were quite autonomous in what they tried and kept working with). That’s said there is not that much use of various activity streams (I’d put blogging in there too) and the degree of using presence/IM/audio/video conferencing tools outside of scheduled interactions varies a lot between teams and people within them. Lots of potential and lots of questions here (will blog on it soon!)

F2f is praised and has lots of opportunities for informal interactions and building a common ground, but resources for it are limited, so, for example, not everyone in a team have met each other in person. I guess part of the equation is how do you add things next to f2f.

Leave a Comment

You can use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

Previous post:

Next post: