Mark Needham

I came across an article written a few months ago titled ‘Outsourcing doesn’t work‘ which discussed some of the problems the author has experienced while working with teams offshore.

The article is provocatively titled but has some interesting observations which I thought I could contrast with my own after working offshore in Pune, India for a couple of months now.

The team I’m working on is distributed between Pune and Chicago so it’s not exactly the same situation as the author’s but the majority of the team are in a different country to the client.

The author focuses on two main issues:

Culture Differences

People in different cultures have a different idea about authority. In America, an entry level developer would be expected to answer “no” if a CEO asked him if he could finish a complex project by the end of the week. Under commit and over deliver is an established business mantra here. In many Indian or Asian cultures, the right thing to do is say yes since an authority figure asked you, although they would not be able to deliver.

I remember reading something similar about attitudes towards authority in Malcolm Gladwell’s Outliers with respect to the way that the first captain communicated with the captain when flying a plane.

Gladwell described several situations where accidents had happened on Asian airlines due to the first captain feeling unable to question the authority of the captain who was his/her superior.

I haven’t noticed that happening on the team I’ve been working on – sometimes we say we’ll be able to deliver something in a time period and get it wrong but that’s no different to any team I’ve worked on in Australia or the UK.

The main difference that I’ve seen which is potentially cultural is the rhythm of the day compared to what I’m used to.

On the other teams I’ve worked on we’ve typically worked from around 9am until 6pm with maybe an hour break during the day.

Here I find that people are typically in the office from around 9am until 8pm but the breaks scattered throughout the day probably total 2 or 3 hours.

I don’t know if it’s like that even in all the ThoughtWorks offices in India but that’s my observation from Pune at least.

Expectation Disconnect

It is generally accepted that the quantity of bugs (for requirements even specifically cited in documentation) is much higher for an outsourced project than a local one. Furthermore, the concept of well-designed, clean, efficient, maintainable code is often foreign (pardon my pun) with speaking with overseas developer. The only metric is whether or not it works, and it doesn’t even have to work.

As I mentioned in my first post about distributed agile a couple of months ago I’ve found that it’s much easier to build the wrong thing when working in a different time zone to the product owner but I wouldn’t say the ability to write maintainable code is much different.

Having said that, we have sometimes fallen into the trap of only focusing on completing stories and not paying enough attention to technical issues in the code.

I think this is partly due to the fact that since we’re in a different country the main output that people onshore can see is the stories that we complete in a given time period. That therefore becomes the focus.

We have started tracking any technical work we do which we weren’t doing before so hopefully that will help fix that problem

My current opinion on bugs is somewhat influenced by the 37 Signals book ‘Getting Real‘:

Just because you discover a bug in your product, doesn’t mean it’s time to panic. All software has bugs – it’s just a fact of life.

I don’t necessarily think that fixing ‘bugs’ is the most valuable use of time, particularly if those ‘bugs’ describe scenarios which are very unlikely to actually happen anyway.

When you’re onshore it’s much easier to point that type of thing out and then not work on it but offshore since you might only become aware of that ‘bug’ when the onshore team is asleep it’s more difficult.

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!