Distributed Agile: Cultural Differences/Expectation disconnect
Date: 2010-10-17 15:06:18

I came across an article written a few months ago titled 'http://www.codeanthem.com/blog/2010/07/outsourcing-doesnt-work/[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 http://www.markhneedham.com/blog/2009/01/06/outliers-book-review/[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 http://www.markhneedham.com/blog/2010/08/23/distributed-agile-initial-observations/[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 'http://www.markhneedham.com/blog/2010/03/08/getting-real-book-review/[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.