Distributed Agile: Initial observations
The Agile Zone is brought to you in partnership with JetBrains. Learn how Agile Boards in YouTrack are designed to help teams plan, visualize and manage their work in an efficient manner, with support for both Scrum and Kanban processes.
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 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.
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!
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, 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!