Overcoming Cultural Differences with off-shore people

Question

starting position

At the moment I have different test teams at my disposal who work on different continents or who accompany my project like now in India.

I have noticed a wide variety of cultural characteristics:

• There is no contradiction (no matter how meaningless an instruction would be)
• Even if you ask for feedback or criticism, there are hardly any realistic answers.
• So the customer (me) is always right, but exactly, that is a wrong view as I think. I expect comprehensive criticism and feedback from testers. Especially in my project I need negative feedback at an early stage to solve problems directly.
• I have a team leader in India who does not allow direct questions to the testers. So I discuss 3 corners in an awkward way. Very cumbersome. Is this also a cultural habit? I do not know in such a way!

Problems

I currently see the problem that assessments of my projects, just from the QA field, are too positive. Am I wrong?

Solutions?

How can I prevent cultural differences in the test, across continents, across time zones, and local cultural differences?

Or is it really because I'm too bureaucratic as a German ;) Maybe I shouldn't see some things so doggedly?

Maybe someone from India who might be able to explain the cultural differences to me and how I can best build the team.

Answer 1

I expect that your remote testers see their job the way it is defined for nearly all the organizations that use them: does the software work? and can they sign off on that and get paid?

If you create an arrangement where their pay and employment is dependent on giving much greater feedback it will happen, though you'll need to invest time and training because they are not used to this

Ultimately 'off-shore' testers may add limited value because of such issues. you may ultimately find it more value to employ two local workers at $100,000 each rather than 20 off-shores at $10,000 each. Also when you have a lot of people, human notions of shared responsibility leads to 'it's not my job' sorta issues. Whereas when there are just 2 people and they are in-house you can focus better on the real value they add. There can be a greater sense of responsibility and pride in work this way.

To start operating this way you will also need to educate 'not in the moment of any given issue or test. You need to set up separate meeting(s) where you go over the requirements for constructive criticism in details. As with most messages about changes that are not usual to an arrangement, you'll probably need to repeat it several times.

Also this does happen to on-shore core developers too. I have worked in shops where code reviews are largely a 'thumbs-up' exercise and not the vigorous debates they are supposed to be.
So the culture problem here is not about place, ethnicity, etc, it's more about the culture of development, agile, seeking feedback, etc.

Answer 2

This doesn't have anything to do with cultural differences. It's the issue with the organization's work culture. To fix this , you have to ask yourself some hard questions.

1. How independent is the test team
2. What are the KPI used to validate QA efficiency
3. Is bug count and defect detection ratio could be considered as KPIs
4. Does testers get appreciated and recognized on finding design flaws or other bugs
5. Does there is an organizational culture that give more respect to developers than testers
6. Does proper skill upgrade opportunities are given to testers
7. Is there huge salary gaps between developers and testers
8. Does the organization addresses job security concerns
9. Is there a strong QA manager who stands with the team on all issues.
10. Does testers get onsite opportunities , and get involved in early test stages like design, product backlog creation etc.
11. Does the developer explain the bug and bug fixes in a technical manner to the test team? ( This helps in getting QA team more interested in the product )
12. Is there a proper process in place? For instance, what is definition of done, when is a user story ready for testing, how bugs are traced, is there a maximum defect backlog deadline.
13. What factors, who and when does defects will be marked as no fix, deferred, or fix required
14. How are promotion decisions are made
15. How often do team building activities happen

There are tons more , find the human factor and the technical factor. Then the issue will be resolved in no time.

If nothing works then you have to take the hard decision of replacing current workforce with more passionate testers , who does testing because they love it and not because they hate development.

NOTE: I as a QA would recommend to have bug count as a KPI. I believe that it keeps testers motivated about their efforts. But should never use it to measure efficiency of dev team.

And also make sure bug count should be related to feature complexity. Sometimes some QA gets complex features with less bug , but that doesn't make them less productive. In short , have a mix of KPIs and human factor in your decisions.

Answer 3

TBH this doesn't come from the culture characteristics, if so: Indians are some of the most unaccepting of many cultures that i have worked with.

From my past experiences with Clients (Having managed many QA offshore teams)

The problem here is the way we work in Agile(Mostly)

It is highly results-oriented where all the teams(not just QA) are focused on delivering their job, thus much less focus is on the bigger picture viz. the ultimate value proposition of your application or what is the MVP or what is the job that your product is made to do.

And all this leads to what?

• Lack of the motive for the end goal (it's all about delivering it right)
• Disconnect from the actual idea. ( nobody really knows what they're working for)
• Insecurity. (If you do not know what the product is supposed to do, you would rather not say anything that may sound foolish and un-related)

Thus what is more important here is educating the team about the utmost value of the product and give them time to respond instead of rushing.

Not to deny that a team of non-thinkers is going to solve any of the issues.

Of course, you can always change the team but i believe it's more about the process.

some of my great experience was with clients when we worked with them on their projects as an off-shore team(Astaqc.com) and they never treated us different, shared their goals and views, this would help us deliver them more values than shiny reports. ciao!

Answer 4

I work as an offshore QA in India and to some extent I agree to the problems shared in this questions.

But this is not a cultural difference issue, instead it is organizational, leadership and engineers training challenge

Many companies have mindset that keeping client happy by agreeing to their all proposals would keep them in business, rather it would irritate the client when he is not getting feedback and suggestions for improvements in product and processes

You should hire a company that works as your partner rather than just QA vendors.

If the culture of the company is not to ask questions, then the engineers would be executors only.

So try to understand about the company processes and culture. You can also interview the candidates before hiring how expressive they are in sharing their thoughts.

There is definitely a advantage in onshore-offshore model, but the team has to be thinking team and not 'just follow the instructions' team.