One of the mindset differences that often lead to issues in cooperations across cultures is quality versus speed. I believe this is a cultural difference that needs to receive attention in any offshore collaboration. It can result both from a country’s cultural perspective as well as a company culture.
To illustrate the point, I will share an example. In one of our projects, an Indian programmer cooperates with a Dutch software development team. The scrum master is in the Netherlands and the product owner as well. The team uses two weekly sprints and decides on the user stories to be completed in the sprint planning meeting preceding the sprint (they use planning poker as well).
The programmer in India commits to a certain sprint. His mindset is on delivering all user stories from that sprint within the given sprint. This happens often in projects that I am involved with; somehow developers keep the mindset of having to make a deadline, but scrum declares a shippable delivery by the end of the sprint more important than finishing every user story in the sprint. Because the developer (in this case working on his own remotely) commits to the sprint, he could as well move some of the user stories to the next sprint or the product backlog. But he is keen on finishing all. The result last week was that the user stories were finished but not at the quality level expected by the customer.
From the programmer’s perspective, he has been working very hard to show the customer that he can achieve results. But in the end he gets a customer that is not fully satisfied.
In another project, a related thing happened. The programmer wanted to get the work done within the sprint. Because of time pressure, she chose to code the solution according to her own insight. The customer didn’t understand why she chose this solution. Had the scrum master done it himself, he told me, he would at first have spent more time understanding the product and the business she was working on (it is a recently started project so the developer does not have all the system and domain knowledge yet). On top of that he would have spent more time researching on the Internet for re usable code or a useful framework (and he added that most Dutch programmers would have done this as well). But our (Indian) programmer didn’t do that.
What causes these issues to appear in cross cultural cooperations? (I have used two examples from India but I could as well describe one from Ukraine).
I believe the root is in the mindset of the programmers. They see themselves as ‘coders’ and pride themselves in getting work done. Because of this mindset, they feel that they cannot spend time on researching, on spending time using Google to see how others solved similar issues. Because they have work to do, they don’t invest their time in diving deeper into the product or domain they are working on. They want to get clear tasks and get going with the coding. I believe that in India, the system stimulates this too. Most companies operate in strong hierarchy that is unknown to Europeans. There is an account manager responsible for client relations, a project manager for the overall project planning and communication, a team lead that distributes the work to the developers and then we have a programmer without big responsibilities other than producing code. On top of this, the tester will test the code by the way.
Most European companies have the opposite mindset, they prefer quality over speed, they prefer a programmer telling them he can’t finish a user story and proposes to move that to the next sprint because he needs more time to research and test another user story.
I see a few practical ways to change such issues from happening.
1. The first is to consistently stimulate the developer to invest time on research, to remind him consistently that quality is more important than speed. This will have a long term beneficial impact.
2. Plan for research, testing, domain investigation within the sprint. Create a separate task for this, assign a certain amount of hours to the task, so the developer knows it is ok and expected to do research, to test work very well before committing code.
3. Have a clear definition of done (so the developer will always know what is expected of him) and add acceptance criteria to the user stories.
4. Take enough time in sprint planning sessions to discuss solutions, before the developer starts the coding. Stimulate the developer to explain the proposed solution, estimate the workload and reach agreement on that solution. If he doesn’t know yet, add research time to the user story and let him describe the solution to you during the sprint before implementing.
5. Create clarity on the hierarchy within the scrum team. Developers, especially in India, often see the scrum master (especially if he is from another country and working in the customers company) as a superior. They have learned that it is not ok to correct a superior in general, so they might hold back in sharing solutions with you and asking questions. They assume the superior knows best and will prescribe what to do. Keep repeating that the roles are all on the same level and reward ideas, suggestions and own initiative.