Mark Needham

Thoughts on Software Development

Distributed Agile: Initial observations

with 7 comments

One of the reasons I wanted to come and work for ThoughtWorks in India is that I wanted to see how a distributed agile project is run and see the ways in which it differs to one which is done co-located.

I worked on a project which was distributed between Sydney and Melbourne in 2008/2009 and while some of the challenges seem to be quite similar to the ones we faced there, some are completely different.

Emails

Emails become much more prevalent when there are people in different locations and one thing that I learnt from the distributed project in Australia is that we have to be quite careful about the way that we phrase what we write.

It tends to work much better if we write in quite a defensive way using phrases like ‘I think that’ or ‘it seems that’ since it’s very easy to misinterpret what’s being said as we don’t have the chance to understand a person’s body language or tone.

A colleague pointed out to me that it’s equally important to change the way that you read emails to give the other person the benefit of the doubt otherwise everything that you read may come across as being sarcastic and attacking.

Conference calls

As well as emails a lot of the communication between the people in Pune and Chicago is done through conference calls.

We also used this approach on the project I worked on in Australia and while it was still not as effective as face to face communication, the calls were always relatively smooth.

We seem to have more trouble on this project and people’s voices often breakup so that you can’t understand them at all. This leads to a bit of repetition in conversations and I can easily see how this would become an area of severe frustration.

I also learnt that I need to speak much more slowly on these calls or noone can understand what I’m saying!

Time zones

The time zone difference between Chicago and Pune at the moment is 10.5 hours so there is no overlap in the working days in the two locations which means we need to create an artificial overlap.

A normal working day for projects I’ve worked on in the UK/Australia would be around 9am – 6pm:

  • 9am in Pune is 10.30pm the previous day in Chicago
  • 6pm in Pune is 7.30am in Chicago

As a result the people in Chicago are asleep for nearly all of our working day and since the client is there as well the feedback cycle is a bit slower than it would be in the client was in the same building.

There does seem to be more scope to go down the wrong path when building a piece of functionality but as long as the client doesn’t change their mind too drastically overnight or have their intent misunderstood then it seems relatively manageable.

A couple of years ago I saw a talk by the former Managing Director of ThoughtWorks India, Dharmarajan Sitaraman, in which he outlined some of the challenges of offshore and I wondered whether the concepts of successful delivery both on and offshore were the same.

I’m still of a similar opinion but by being part of a distributed agile team for a few days I can see how much more tricky it is to achieve this than it would be in a co-located environment.

I’m sure there are many more things I will notice that are different as times goes on!

Written by Mark Needham

August 23rd, 2010 at 2:52 am

Posted in Distributed Agile

Tagged with

  • skim

    Hi Mark, great post on the topic of distributed agile. One question for you, how does a distributed agile team work in an environment like Pune and Chicago? Does each team trade-off working early/late to create overlap where they can communicate and create feedback cycle?

    Thanks!

  • http://www.markhneedham.com Mark Needham

    I guess a bit of both actually although I think the working times of the Chicago guys are more impacted. They tend to be awake quite late at night so we can talk with them in our mornings.

  • Chandan

    The issues outline are tip of an iceberg, it becomes even more complicated. I got around 3+ years of experience working in distributed agile, some “real” issues also include:
    1.> If there is a lack of motivation on any end, it can easily end up “waiting” for feedback kind of status updates
    2.> When we have not met a person, we really do not know how he likes to communicate and communicated –a lot of preparation goes in “how to present”, “am i making point ” –all result of “too formal” culture which i always consider a bottleneck for team
    3.> Missing to show up at meeting for any circumstances, which makes dependents’ team next day useless

    Not to say these issues could be handled cleverly, pulling out stories till the feedback is available –but then most of time, in my experience, it results in stuck up state.

  • Pingback: Tweets that mention Distributed Agile: Initial observations at Mark Needham -- Topsy.com

  • http://myopendraft.blogspot.com/ Alireza Haghighatkhah

    Nice Post, thanks for sharing, In My experience, we should more and more pay attention to communication issues in distributed agile teams, here is some of best practices :

    - Each site conducts a local standup in their morning to address immediate issues.

    - All teams join a daily teleconference standup, ideally scheduled at a common work time for all. A video-conference standup is better.

    - Each location has a Scrum Master Proxy and a Product Owner Proxy. The proxies synch with their counterparts regularly and learn to guide their local teams and keep them productive.

    - Team members visit other sites to deepen relationships and information exchange.

    Technology can play a role in mitigating some of the challenges of distance. VOIP and webcams can go along way to overcoming cultural awkwardness and maintaining a co-located feel.
    It is worth the extra effort to get these technologies working. Distributed teams also need to implement a collaboration tool to function as a virtual task board.

    Examples include wikis at the low end and more specialized products like Rally Software, VersionOne, Xplanner.org, and Atlassian Jira with the GreenHopper plugin. There are many other tools, and you should be able to find a solution that fits your needs and budget. As an aside, if you have only one remote team member, the Scrum Master can usually support that person and the team can still even use a physical task board.

  • http://www.markhneedham.com Mark Needham

    @Alireza – thanks for sharing your thoughts, interesting stuff.

    I think we’re doing most of the things you suggest so that’s good at least!

    One thing which is interesting is the story wall. We’re using Mingle as the source of truth but when I started working on the team didn’t have a physical story wall.

    The reason for that is because it was ending up that the physical wall would be updated and Mingle wouldn’t so the guys in Chicago wouldn’t be up to date with what was happening.

    I think you lose something in the way the team communicates by losing the wall though and I think it’s worth taking the hit of having to update 2 different data sources for the value you get from that improved communication.

    Any thoughts around that?

  • http://www.teleplace.com Perry Mizota

    Just came across your post, Mark. At Teleplace, where we have a software solution that provides virtual workspaces for business collaboration, we have found that the management of distributed agile teams is a great use case for virtual workspaces. We just published a blog post on this topic at http://teleplace.wordpress.com/2011/01/25/finding-a-place-for-distributed-agile-teams/.