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.
merci !Clarisonic Mia Sale In Deutschland, lassen Sie Ihre Haut geworden gesund!
I think the point is that a lot of engineers all over the world, even college educated ones, live and are raised in a culture where you ought to obey your role in an organization at all means.
So, if you are a programmer you are not a researcher and also not a project leader.
The scrum master in this article wants to have the best of two worlds. The low fee from the Indian programmer and the flexibility and entrepreneurship from the scrum master.
And yes, a Dutch programmer would not mind to reuse software from somebody else. But there are cultures who see this behavior as not done (to put is mildly). You pay them fore programming work and that is what they do and deliver.
So probably, in this situation the scrum master better had hired a Dutch programmer.
My two cents for today
Koos
I agree with you that we need to add task for testing.
Mostly what happens is when we estimate, we give the time that we will take to finish . That means the productive hours. In a day I assume only 6 Hours will be productive out of 8 . That means we have IM, calls and in middle frustrations for things needs to be changed / bugs reported.
So when small tasks comes in middle, like say 15 minutes . We want to login to Jira , look into the functionality, implement it , test it, commit to server and yes we are not just in 15 minutes sometimes.
So that means there should be some room for the person to breath
.
And I agree that most people in India thinks we need to finish the sprint . I never thought of moving out from the Sprint for I was also the person who made the Sprint . So thank you for the point that we can move a task to next sprint when we need.