Archive for the ‘Distributed Agile’ Category
I’d always heard that communication when you’re working offshore was much more difficult than in a co-located team but it’s quite difficult to imagine exactly what the difficulties are until you see them for yourself.
These are some of my latest observations in this area so far.
I’m a very visual learner and the majority of the time any communication between people in two different locations will be done through words either via email or on a conference call.
Of course it is possible to do remote white boarding but that increases the overhead of the calls and sometimes participants in these calls only have their phone available and don’t have access to their computer or the internet.
I tend to find myself sketching out conference call conversations on a white board so that I can follow what people are talking about.
You lose the instant feedback that you get when doing this with someone else but I find it easier to understand diagrams than paragraphs of text or dialogue describing something.
Duplication of discussion
Due to the fact that we can’t just grab everyone in the team and go into a room for 20 minutes to discuss a design approach because half of the team is in another city.
We often end up having a meeting in Pune and then a similar one later in the day over the phone with people onshore and a parallel conversation going on over email at the same time.
It’s been significantly more difficult to get consensus on any decision with this style of communication than it would be if everyone was in the room.
In that environment you can easily read body language and see if someone doesn’t quite buy into what is being suggested.
Thinking how to phrase it
I think this is just generally a skill which requires more skill in non face to face communication and the conversations tend to be much more sugar coated to avoid offending people.
I don’t think this is a bad thing but I find that face to face conversations can often be more direct without someone getting offended or spending time trying to work out if there was a hidden message in the other person’s communication.
The risk here is that we can end up spending a lot of time working out how to word our communication and lose the point that we were actually trying to make in the process.
Working with outside teams
If working with other people on the same team in a different country is tricky it becomes even more difficult when communicating with outside teams in the remote location.
For example we often have to interact with a client’s operations team and in a co-located situation someone on the team would probably have met people on that team personally.
In a distributed situation you don’t have that so if you have a request for them then you tend to communicate via email.
Since they only know you by your name on the email I’ve noticed that it takes significantly longer for things to get done than if you could just go and speak with them.
These are just some of the things I’ve noticed and I do admire my colleagues here for learning how to work effectively with these constraints because it’s been amazingly frustrating for me so far.
When I started working on my current project there was no physical story wall, instead the whole project was being tracked on Mingle.
The current state of the Mingle story wall was sometimes visible on a shared monitor and sometimes wasn’t, depending on whether or not the monitor had been turned off.
There was also a small wall used to track which stories were in development but after that there was no physical visibility of the status of anything.
The advantage of this approach was that there was no need to have the overhead of having to maintain a physical story wall and an electronic one.
The disadvantage was that it was quite difficult to see what people were working on and there was a very definite split between development and testing.
Mingle and similar tools are useful in distributed teams but they are information refrigerators in the sense that you have to put in some effort in order to get information from them – it’s not immediately available to you.
The physical story wall on the other hand is an information radiator which is what we want!
In the case that we get around that problem by using a projector to beam the web page onto a wall I still don’t think it’s as effective because it’s less human to deal with a projection than a real card wall.
I find it’s much more effective for people to be able to move cards around with their hands and then move people in between those cards depending on what pairings make sense at any given time.
The collaboration on my team seems to have increased quite dramatically since we made the card wall physical and I’d be surprised if the overhead of updating Mingle and the story wall was more than 5 minutes per day.
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:
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.
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 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, 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!