Mark Needham

Thoughts on Software Development

Archive for the ‘distributed-agile’ tag

India Cultural Differences: Hierarchy

with 2 comments

One of the more interesting differences between Indian culture and my own is that in India there appears to be more adherence to a hierarchy than I’ve experienced before.

ThoughtWorks tries to keep a reasonably flat hierarchy so I think the idea of hierarchy would be much more obvious if I was working at one of the big Indian services organisations.

Between peers conversations don’t seem to play out any differently but someone in a position of authority is more likely to be able to get their opinion across and accepted with less resistance than they might experience without that authority.

On several occasions it’s been only me and maybe a couple of others involved in discussions if someone in an authority position expresses an opinion assertively.

I asked several colleagues why this was and they pointed out that when they’d previously expressed an opinion in that type of situation it didn’t have any impact so they’d stopped doing so.

I can’t decide whether or not it really matters – the situations where authority has any influence are relatively infrequent – but it would be cool if all opinions were assessed just on merit.

Of course these are just my observations so it’d be interesting to hear others’ experiences.

Written by Mark Needham

December 27th, 2010 at 2:16 pm

Posted in Distributed Agile

Tagged with

India Cultural Differences: Language

with 6 comments

For the majority of the time that I’ve spent in Pune so far language hasn’t been a big deal at all but there are a couple of differences that I didn’t initially anticipate.

The local language

While the official office language is English my colleagues seem more comfortable talking to each other in Hindi so quite frequently the conversation will move into Hindi if someone isn’t directly speaking to me.

I initially found it tremendously frustrating that I couldn’t understand what was going on in group discussions and while I did point it out people don’t realise when they’re switching into Hindi so it’s a difficult problem to fix.

My brain now seems to zone out when people stop speaking in English so I don’t even notice that it’s happened unless I observe myself becoming much more aware of my surroundings because I’ve tuned out and started looking around the room.

An interesting side effect is that I don’t pick up as much information from osmotic communication as I have done when working in the UK/Australia because conversations between my colleagues have a 50/50 chance of being in Hindi.

I guess the easiest way for me to fix the problem would be to take lessons in Hindi but I’ve never got around to that.

Another interesting thing to note is that it’s not only me who doesn’t understand Hindi but also people from the Chennai office.


Swearing in India is a bit of a taboo which is quite strange for me because in the UK/Australia there’s not really any stigma attached to the majority of words.

There are a few people who are more easily offended so you have to be a bit more careful about word selection when speaking with them.

Having said that, with the majority of people that I’ve worked with the language that I use makes no difference at all.

Written by Mark Needham

December 24th, 2010 at 6:12 pm

Posted in Distributed Agile

Tagged with

India Cultural Differences: Stretched work day

with 5 comments

A couple of months ago I briefly touched on the very stretched days I’ve experienced while working in India.

This is in contrast to what I’ve experienced in the UK and Australia where the day was much more time boxed and tended to go from 9am to 6pm.

At the moment we also have a call with colleagues in Chicago at 9pm for about 30-45 minutes so the day has now stretched out until nearly 10pm. We start with our standup at 10am.

We’re certainly not working all of that time but you’re never really done for the day until the call has finished.

With or without the call I’ve found it a much more difficult environment to work in than anything I’ve experienced before.

I frequently get to the end of the day and can’t really determine whether I’ve actually achieved anything because I’ve started and stopping working so many times.

I find I get distracted really easily working in our Pune office so I need my pair to be quite vocal about keeping focus!

One disadvantage of the stretched work day which I’ve only noticed recently is that you can become less reflective about the code because you don’t get as much time where you’re awake but not directly working with the code.

I frequently came up with possible ways to improve code bases on previous projects while playing around with something else or watching a presentation or similar.

I find that I play around with stuff outside the project less than I have previously partly because I’ve lost the 4 to 5 hour stretch that I used to have each evening.

On the positive side you get to know the people you’re working with pretty well because you’re with them for a lot more hours per day.

Not every project in the office has hours as stretched as mine but it certainly seems to be more common in India than elsewhere.

Written by Mark Needham

December 20th, 2010 at 9:23 pm

Posted in Distributed Agile

Tagged with

Distributed Agile: Bringing onshore people offshore

with one comment

For the last two weeks we’ve had a ThoughtWorks colleague from the onshore team working with us in Pune and it’s been really cool having someone who has been working on ‘the other side’.

In my time in India there seem to have been many more people going from offshore to onshore than the other way around but based on this experience I don’t think that should necessarily be the case.

The typical argument in favour of someone from offshore going on site is that they’re able to interact with the client and onshore people and pick up any required context which they’ll then be able to share with their colleagues offshore.

The impact of those trips is perceived to be higher than what would be achieved by having someone do the reverse trip.

Having seen the interactions my US colleague was able to have with people has made me realise that perhaps that perception isn’t as true as it seems.

A big part of the success of distributed projects seems to be about the ability for the two sides to communicate effectively and having someone who interacts daily with people that we only know by phone/email is very helpful.

My colleague was able to provide context about our client and what they’re trying to do in a way that I don’t think someone going onshore for a couple of weeks would be able to do.

Sometimes it’s felt like we’re just building something because we were told to do so and my colleague has been able to explain the underlying thinking and what we’re trying to do with the system.

I think he’s also found it a pretty useful experience in terms of learning about the strengths and weaknesses of the team and what the real pain points are.

Everyone offshore now knows one person onshore personally which should be useful for any future interactions.

Written by Mark Needham

December 20th, 2010 at 8:58 am

Posted in Distributed Agile

Tagged with

Distributed Agile: Other observations

without comments

Some of the difficulties of working in an offshore environment were clear to me before I even came to India but I’ve come across a few others lately which I either didn’t think about before or didn’t realise how annoying they were!

Getting data from the client’s network

For several of the stories that we’ve been working on lately we needed to make use of huge amounts of reference data residing on the client’s network.

If we were working in the same building then it would be very quick to download that and use it for whatever we needed.

Working offshore we’ve been downloading those dumps via scp which can take around 5 hours for a 300 MB file.

I don’t know a lot about networks but I’m told that it would be possible to create a direct VPN between our office and the client’s which would allow the transfer of this type of data to be much quicker.

Dealing with internal IP addresses

Since we’re working on a different network any IP addresses for test environments of external systems aren’t directly accessible.

We have a box setup in our office connected via a VPN to the client’s network which forwards requests we make to local IP addresses to the equivalent IPs on the client’s network.

There have been several occasions when there have been internal IP addresses hard coded in our configuration files and we’ve completely forgotten that we need to create an equivalent local address.

It’s not a big time waster but it’s something you wouldn’t have to think about if working in the client’s office.

Slowness of the feedback cycle

It’s obvious that if the client is in a different country to you that there will be less face to face communication but I didn’t realise how frustrating that would be.

If you have an observation about a piece of functionality and the offshore BAs don’t have the answer then you’ll most likely have to wait 5/6 hours to speak to someone onshore about it or write your thoughts in an email.

While both of those are viable options I find my motivation to express my opinion is much lower if I can’t get feedback straight away.

As a result of this communication lag I think that we spend more time building functionality which doesn’t necessarily add a lot of value.

Written by Mark Needham

December 12th, 2010 at 8:11 am

Posted in Distributed Agile

Tagged with

Distributed Agile: Communicating big design decisions

with 2 comments

Although we mostly split the work on my project so that there aren’t too many dependencies between the teams in Chicago and Pune, there have still been some times when we’ve designed major parts of the code base in Pune and have needed to communicate that to our Chicago colleagues.

I’ve never seen this situation so it’s been interesting to see which approaches work in trying to do this effectively and allowing the people in the other location to have input as well.

Explanation on specific email threads

While it’s useful to communicate the approach being taken by email we’ve found that it makes more sense to have a specific email thread for that conversation rather than tagging it onto something else.

It’s surprisingly easy for emails to get lost amongst the hundreds of others that people receive each day but at least if the important messages are all under an email with a clear title then it’s much easier to deal with.

While discussing this with Saager, he suggested that an effective approach he’s used previously is to include details of design decisions taken in commit messages and then point people towards those particular commits.

Of course however skilful we may be in communicating via email it does help to talk on a conference call as well – that medium seems to work better for explaining the reasoning behind decisions, especially if there’s a disagreement in the approach.

Commit early

As much as we can explain design decisions in emails or conference calls it’s still not as useful for people as seeing the actual code which is something we didn’t totally appreciate until recently.

We’re now trying to ensure that we check in more incrementally when making big design changes.

This should help to tighten the feedback loop and ensure that we get the benefit of the design skills of people onshore as well as offshore.

Something which I initially considered as a disadvantage with checking in incrementally is that you will most likely get suggestions/criticism about what you’ve done even if you had already planned to address some of those areas anyway.

As a colleague correctly pointed out, the intention is generally good and it’s not the end of the world if someone suggests something you could have done better anyway.

In summary

These types of things seem obvious looking back at them now but I guess it isn’t so obvious to me because you never have to think about them at all when anyone interested in the code is sitting in the same room as you as it’s been for me when working onshore.

I’d be interested to hear any other approaches that have worked well for others working in a distributed fashion.

Written by Mark Needham

November 10th, 2010 at 7:58 pm

Posted in Distributed Agile

Tagged with

Distributed Agile: Communication – Reliance on one person

with one comment

Continuing with my series of observations on what it’s like working in a distributed agile team, another thing that I’ve noticed is that it’s useful to try and ensure that there is communication between as many people as possible in the two cities.

This means that we want to ensure that we don’t have an over reliance on one person to handle any communication.

We have a call once a day between developers in Pune and Chicago and the Chicago guys have been able to achieve this by rotating the person attending the call.

In Pune we’ve typically had half the developers attending the call but perhaps only one or two actually speaking.

I originally didn’t think of this as being a problem because those two guys were really good at communicating and in other teams I’ve worked on we’d typically have the tech lead and maybe one other communicating with other teams.

In this case we are communicating with people in the same team and by chance a few weeks ago both of the main communicators from Pune were away at the same time so we had to have the Chicago call without them.

Perhaps unsurprisingly others were able to fill the gap that had been left and as an added benefit the guys in Chicago had now had the opportunity to interact directly with more people from Pune.

A interesting and positive side effect I’ve noticed is that the people who had now started communicating directly with team members in Chicago seemed to become more involved in the project as a whole and are now also more likely to communicate via email than they may have been previously.

Our challenge now that both the original guys are back is to ensure that the whole team still remains involved in communication with Chicago and don’t delegate back to those two every time.

Written by Mark Needham

November 8th, 2010 at 1:56 pm

Posted in Distributed Agile

Tagged with

Distributed Agile: Context

with 8 comments

From my last couple of months working for ThoughtWorks in Pune I think the most common subject that I’ve heard discussed is how to ensure that the team offshore is receiving all the context about the decisions and direction being taken onshore.

What I’ve found most interesting is that I think out of all the teams that I’ve worked on in the last four years my current team has by far the most context about what the client wants to do and the approaches they want to take over the next few months.

I think the main danger of trying to provide this level of context is that it almost inevitably leads to over communication.

Three of my colleagues from Pune recently went to Chicago for a few weeks and having returned to Pune want to share the context they got in Chicago with us.

I’m a fan of pulling information when you actually need it so my preferred approach was to discuss each of the functional areas closer to the time that we’d actually be working on it rather than having the guys effectively do a brain dump on everything they’ve learnt right now.

My reasoning is that I find that I struggle the most to learn when someone gives me a whole load of information which I can’t really connect to anything – i.e. information out of context.

The new design of ThoughtWorks University provides an example of how learning in context can be very effective.

Interestingly I was significantly outnumbered by my colleagues when we voted on which approach to take. They preferred to receive the context up front rather than later on.

I decided to go to a few of the sessions anyway and while the context has been well presented, I am finding that I forget the specifics of those sessions pretty quickly since I don’t have anything to link the concepts to nor am I using the information I’ve learnt right now.

I’ve also noticed less and less people attending these sessions for similar reasons.

My opinion on this type of thing is that as long as I know where I can get the data from when I need it then that’s enough. I don’t need to have all the details up front.

I’m not sure if this observation has anything to do with the team being offshore, if it’s a cultural thing or none of the above.

It’d be interesting to hear about others’ experiences.

Written by Mark Needham

October 31st, 2010 at 6:27 pm

Posted in Distributed Agile

Tagged with

Distributed Agile: Communication

with 3 comments

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.

Learning models

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.

Written by Mark Needham

October 27th, 2010 at 1:50 pm

Posted in Distributed Agile

Tagged with

Distributed Agile: Physical story wall still useful

with 4 comments

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.

Written by Mark Needham

October 20th, 2010 at 5:21 pm

Posted in Distributed Agile

Tagged with