Working with on/off-shore team members challenges?

Testing Thoughts
#1

Having worked with a number of different teams who were a mixture of co-located & on/off shore team members I was wondering what challenges were faced with communication?

I think my hardest was actually a co-located team but everyone had a heavy accent (including myself) from all parts of the world, France, S/Africa, Australia, China, Russia, NZ & India. We all sat together but the amount of times we talked face to face but had misunderstandings was amazing. It seemed a lot more difficult than when I worked with a complete dev/test team off-shore but that could be just my experiences.

I am interested in everyone elseā€™s experiences and what did you or your team do to mitigate any issues if you had any at all?

1 Like
#2

Iā€™ve worked with a lot of off-shore teams, mainly in India and Romania. My main challenge has always been to make sure that Iā€™m speaking clearly and not too fast so that itā€™s easier for them to understand. I found I was guilty of talking quickly and not acknowledging that they were having to convert what I was saying into their native tongue.

I think, as with any good communication, ensuring complete clarity of understanding is really important where issues or decisions are made.

I think with the tech we have available (Skype, Slack, Zoom etc) itā€™s easier than ever to communicate with colleagues. I work just as easily with people off-shore as I do with those in my office.

2 Likes
#3

The last time I worked with off-shore team members, it wasnā€™t possible to use voice or video chat, so all discussion happened over instant message (this was around 03/04-ish). The biggest problem I found was that while most of the people I worked with were reasonably fluent with formal English, they had little to no experience with any kind of informal English.

That meant I had to avoid any figures of speech, slang, dialectā€¦ Even conversational English could be problematic for some of the less fluent team members.

On the plus side, many of them took the opportunity the chat tool presented to message the on-site team members so they could improve their English comprehension. It was an interesting experience and sometimes we needed to go back and forth several times to make sure everyone understood what everyone else was saying.

2 Likes
#4

In my last role we did two large projects. The first involved a team of developers in London, just 100 miles down the road from our office in Leicester. Communication was at best average; we had a couple of start-up meetings at the outset of the project, and then communicated manly via e-mail and a weekly conference call via voice telephony, which was all we did until they came at the end of each four-week sprint to demo the finished application features. We werenā€™t involved in any of their scrum ceremonies and communication was pretty poor generally.

For the second project, we engaged a team of developers (and one tester) in Chisinau, Moldova. The company was used to remote working and their project manager was based in Bristol (UK) (most of the time - heā€™d head back to Moldova one week out of four). We communicated daily in real-time using IM, video conferencing and electronic sharing of the scrum board. Our working with this team was far superior to that with the London devs; we developed good working relationships very quickly, the team in Moldova were always available and they structured a lot of their working around working to UK time. Their English was far better than my Romanian, and no-one was afraid to ask to test our mutual comprehension. I enjoyed that off-shoring experience far more than I did working with the London team, and I was quite upset when my employers pulled the plug on that project for purely selfish capitalist reasons.

3 Likes
#5

Yes Kate I found I was guilty of that too using figures of speech etc. Even here in Australia (I come from New Zealand but lived here 20+yrs) I found I donā€™t understand some of the slang or dialect. Interesting isnā€™t it as its not a English comprehension issue but a figure of speech created within the environment the person grew up in.

I worked with an Indian team and had a lot of fun teaching them figures of speech and they taught me more about their culture. It was a very successful culture exchange and I made some wonderful friends.

2 Likes
#6

Kim, this is something Iā€™ve had to think about, though I feel itā€™s one of those things that makes life interesting.

When I was working with the Moldovan team, one of the things we were looking to implement on the call centre application we were working on was UK-specific geographical information to match callers with potential FM contractors in their area. One of the main criteria was whether the caller was inside or outside the M25 (the London outer orbital motorway). It made me stop and think when I realised that Moldova has no motorways at all.

#7

I have been on both sides of the coin. Been the offshore person in India when our clients were in UK/USA/Africa/China and also been onsite in these countries trying to work with the dev team back in India.

One thing that helped a lot was having a face attached to the screen-name or email ID. This brought out the empathy in people a lot more. So we tried to have informal video calls once in a while and always for introductions. The more you build human relationships the easier the job gets.

But like you all have mentioned already there is always the fact that we all donā€™t understand the native lingos or the accents or even the demeanor of another country entirely. So one must remember to talk slowly, keep re-iterating the action items both verbally at the end of the meeting and also send out meeting notes to mitigate the accent problems.

A shared board for iterations/releases or even a kanban board is always a good idea. The more visual it is the better !

The last and the most inconvenient problem is that of the timezones though. No matter how hard you try the team away from you might be working at a very inconvenient time for you.And if the offshore team didnt understand what you wanted them to do , its a wasted day for them !
The thing that helped us here was sending out an End of Day update about what can be picked up and what was done by the team. In my exp the BA/QA/PM trio can send these quite easily saving days of billable work in some cases.

5 Likes
#8

I agree on the timezone issue. In the past Iā€™ve had trouble communicating when there is an off-shore team working in an entirely different timezone. When we donā€™t even coincide for a couple of working hours and the communication has to happen for over days, meaning they ask something one day, I respond something the next, ā€˜no that was not what they meantā€™ the next day, different response other day, etc.

To mitigate this issue you can arrange the teams to work in separate groups/projects, if you work for a company that in fact has many different projects happening at the same time. This meaning having an entire functioning team in the off-shore location. Dev/PM/QA. Still thereā€™s eventually gonna be a time when someone is going to have questions that only someone on the other side of the world can answer. And this approach has itā€™s flaws as working in separate projects is only going to make this isolated knowledge thing a bigger problem, right? So taking extra precautions with documentation and knowledge transfer is important.

2 Likes
#9

Certainly when we were working with the London team I mentioned earlier, our working relationships improved late in the project when we agreed that the project manager would physically come to Leicester once a week and work from there - even if he didnā€™t 100% work on our project, just having him in the office and interacting with us improved the working relationship.

Our Moldovan colleagues were certainly well geared up to remote working, with having the project manager working out of the offshore companyā€™s UK office, attending our office at least once a week, and heading back to Moldova one week in four. With that and real-time video availability and IM, our working relationships were amazingly close. Had our company not pulled the plug on the project as a whole (for wholly unrelated reasons), it was intended that in later phases there would be the opportunity for exchange working on a broader scale, both in terms of more people and for longer periods, and in both directions.

1 Like
#10

Interestingā€¦ because I came across a similar situation as yourself. Here in Australia when you register a vehicle at the same time the owner must purchase government third party insurance (which insures when humanā€™s are hurt during a vehicle incident) which is different to insurance for the vehicle itself.
I was working with off-shore development team where their country has never instituted that sort of insurance and I quickly realised I took a lot of my understanding (having purchased it a number of times) for granted.
These can sometimes be tricky to spot. :face_with_monocle:

#11

Exactly. In the UK, the legal minimum insurance that a driver has to have covers third party liability, though it is provided by insurance companies (who then use it as an opportunity to upsellā€¦) It is usually lumped in with a ā€œslightly better than minimumā€ policy, known as ā€œThird party, fire and theftā€.

It reminds me that one problem we had with the London team I spoke of earlier was over expiry dates. That London team was pretty cosmopolitan, and formed of people who did not have a lot of experience in UK administrative processes. I kept reporting a bug to say that agreements with an expiry date were expiring 24 hours too early, and it kept on not being actioned. (Not even being described as a ā€œWonā€™t fixā€ which would have alerted me earlier to the problem.)

It turned out - when I did some digging - that the devs in that team were all applying US practice to expiry dates, which is different to UK practice. In the UK, if something expires on 1st January, it expires at midnight on 1st January: 1st January is the last day something is valid. But in the US, something expiring on 1st January will expire at midnight on 31st December: 1st January is the first day something is not valid. With so much proprietary software being of US origin, and with a group of devs from an international background, no-one had realised that US and UK practice differed. It was only because I have a past in UK Government administrative practice that I spotted this and had to insist it was fixed. At least I could explain why.

#12

Goodness our testing experiences mirrorā€¦ and that is exactly what is takes that digging and not being willing to let it go because your gut instincts tell you something isnā€™t right.
Job well done Robert :):+1:

#13

Hi Robert, I suspect Iā€™m working with the same off-shore company. Having spent the best part of 30 years working with at least some of my team working remotely Iā€™ve found that the teams Iā€™m working with in Moldova and Romania have actually exceeded my expectations. Weā€™re working on legacy products at the moment which is always tricky for new team members but most have coped really well with code of up to 20 years old. As you say, their language skills have been excellent (down to use of colloquial expressions that Iā€™d not have expected many native speakers to use) and being able to increase/decrease team numbers as projects require works really well. My advice to anyone off-shoring is to pick the company you work with very carefully ensuring that you have an account manager who really understands your requirements and you work with a company who really invests in their staff, also make sure you have sufficient processes in place so that everyone understands the working patterns. Interestingly, back in the early 90s I worked with an off-shore team in India and certainly didnā€™t have the same positive experience.

2 Likes
#15

Company has a Latin-sounding name beginning with ā€˜Aā€™, by any chance?

#16

That would be the one.

1 Like