Mark Needham

Thoughts on Software Development

Archive for the ‘Distributed Agile’ Category

Distributed Agile: Stories – Negotiable

with 3 comments

I was recently reading an article about how to write meaningful user stories and towards the end of it the author mentioned the INVEST acronym which suggests that stories should be:

  1. Independent
  2. Negotiable
  3. Valuable
  4. Estimable
  5. Small
  6. Testable

From what I’ve seen the most difficult one to achieve in a distributed context is that stories should be ‘negotiable’, in particular when it comes to negotiating the way that the UX of a bit of functionality should work.

On most of the projects that I’ve worked on the people designing the UX tend to work slightly detached from the development team and then send their designs over as wire frames.

It’s not the most ideal setup even if you’re working onshore but it becomes even more challenging when you’re working offshore.

Typically onshore if a particular user flow was very difficult to implement then one of the developers might go and talk with the UX guys and then explain the problem and give another potential solution.

The trade off between the cost of implementation and the user experience that the UX person has suggested is clearly outlined in these conversations.

When that feedback comes from offshore it has much less impact and I think it comes across much more as a criticism of someone’s work rather than an attempt to be pragmatic in helping the client to deliver a product within a time frame.

One possible solution to this problem if you have some onshore colleagues is to have them go and talk about the problem but we’ve found it difficult to do that because we try to split onshore/offshore stories so that we’re working on different parts of the code base.

Therefore it is pretty difficult for an onshore developer to go and discuss it for you.

To add to the problem we tend to realise the difficult of implementing a certain UX during the middle of our day which means we need to wait half a day to see if we can get it changed.

Given that time lag we often just end up designing it the way that’s been specified so that we don’t ‘waste’ time.

It’s clearly not an idea situation so I’d be keen to hear if anyone has come up with ideas to get around this.

Written by Mark Needham

January 24th, 2011 at 3:34 am

Posted in Agile,Distributed Agile

Tagged with ,

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

India Cultural Differences: Tolerance/Patience

with one comment

Some colleagues have been asking me recently what cultural differences I’ve noticed working in India compared to my experiences in the UK and Australia and one of the biggest differences by far is the amount of tolerance and patience people here have compared to me.

These attributes seem to show themselves in roughly two situations:

With respect to the environment

We’ve had some building work done in the Pune office recently which has meant that there’s been extremely high volume drilling being done to the extent that you can barely hear someone who’s sitting a couple of metres away.

I was quite amazed to watch colleagues continuing with their conversations as if nothing had happened – I was totally distracted and had to go and sit in a meeting room away from the noise.

I’ve talked to a few colleagues about this and they pointed out that they’re pretty used to the environment not being perfect from previous experiences at school or just in general life situations so it’s not such a big deal.

I find it interesting to see how influential the environment (as far as I can see) can be on some fairly fundamental personality traits.

With people

People here seem to give others the benefit of the doubt much more frequently than I’ve seen elsewhere.

I’ve noticed this especially when communicating with people in remote locations.

I worked on a project distributed between two cities a couple of years ago and the distrust between the two locations was fairly evident in all methods of communication.

I haven’t noticed the same thing here as much and the majority of the time people don’t react at all to something which I would consider to be inflammatory.

There’s also much more tolerance for repetition of information than I’ve noticed elsewhere.

I get very frustrated if I hear the same thing repeated multiple times but the majority of people here don’t seem too bothered by that and take it in their stride.

It’s a strength not a weakness

I think that people here sometimes don’t recognise that their tolerance/patience is a strength rather than a weakness and I’ve frequently heard conversations where what I consider being tolerant is seen to be ‘rolling over’.

I don’t necessarily think the ‘western’ style of presenting an argument very assertively/confidently is the only way to go and I’ve seen colleagues successfully communicate while using their own style.

Of course these are massive generalisations based on my observations so it’d be interesting to see what other people who’ve had the chance to work in both cultures/environments think.

Written by Mark Needham

December 15th, 2010 at 7:08 pm

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