Cross-cultural team building enables collaboration and teamwork in dispersed or distributed agile teams. You need to invest to get the best out of a dispersed team argues Nienke Alma, a people oriented Agile enthusiast working as a Scrum master and agile coach. Several more people wrote about what is needed to make agile work with dispersed or distributed teams.
In the article Distributed Agile: 8 ways to get more from your distributed teams Keith Richards stated:
For a high level of performance and for agile to work well in a distributed context, the team needs to function in a collaborative manner and teamwork is at the centre of this.
You need to remove cultural and process limitations so that collaboration can happen between the teams and inside the team, argues Richards.
In an interview with InfoQ on staying connected while working remote, Pilar Orti gives suggestions on how to deal with cross cultural aspects in remote teams:
I think there are two different scenarios to consider here: when you are dealing with a team that is based in another country and when you are working with individuals who are dispersed throughout the globe.
In the first case, team members all based in a country different to yours might share some characteristics in their approach to work, their meal schedules, etc (note that I said "might"). In that case, having a conversation with them to bring to light some of these differences is helpful. Beware of making assumptions though; it’s always best to get the information directly from the team members.
Once these broad commonalities have been brought to light, then you need to remember that the team is still made up of individuals. Which brings me to the second scenario I mentioned, in which people are dispersed throughout the globe. In this case, I would once more find out any obvious differences through conversation, and then get to know them as individuals. There will be things you have in common and things you don’t, but this is bound to happen regardless of nationality.
David Horowitz and Mark Kilby spoke at Agile 2016 about communicating and collaborating in distributed teams:
Distributed teams need to be connected, and while face-to-face is important for collaboration, it isn’t as important as connectedness.
They mentioned three ways to create safety in distributed communication: chat channels, buddy up, and co-pilots.
Nienke Alma gave a lightning talk about challenging the agile manifesto with dispersed teams at the GOTO Amsterdam 2016 conference. InfoQ interviewed her about how a Scrum master can build teams with people from different cultures, how they did code reviews, the benefits they got from doing distributed sprint reviews, and asked her for advice on developing products using a dispersed team.
InfoQ: You mentioned that the Scrum master played an important role in building teams with people from different cultures. Can you give some examples of the things that you did?
Nienke Alma: It started with the hiring process of the team members. As a Scrum Master, I was closely involved in this process and attended all interviews. During these interviews I was more focused on the personality and soft skills of the candidate than on the hard skills. Usually another team member was able to judge these hard skills better than me. During the interviews I tried to find out how the candidate would deal with another culture. Curiosity, flexibility and an open communication style were characteristics I was looking for. Of course I couldn’t get a full picture of the candidate in one conversation, but in general we managed to find the right mix of people for the team.
Also during the sprints it was important for me to make impact on the cross-cultural team building. For instance, we organized short workshops to explore the cultural differences. Moreover, during the usual Scrum events I had to keep an eye on the team dynamics. Are the conversations well understood? Could everyone speak freely? You have to realize that Dutch people will hardly ever hesitate to speak up and may discuss anything that is brought in the conversation, while Indian people are usually more careful about what they say. As a Scrum Master I tried to help the team to make sure that everyone could make an equal contribution to the team work.
InfoQ: How did you do the code review meetings? Why did you do them this way, and which benefits did it bring?
Alma: The code review meetings are a great example of a quality improvement initiative that came from the team itself. Although all team members had the same responsibilities regarding the deliverables of the team, there were differences in seniority between them and so we also saw differences in the quality of the code. Due to the different locations of the team members we found out that peer reviews did not always happen cross-border, even if that would have been the best thing to do. Two senior developers therefore decided to organize a code review session every sprint, which was basically an opportunity to teach the other team members and improve the coding skills of the team.
What I liked most about the sessions was the way the senior developers turned them into a game. Before the sessions they selected a few pieces of code that contained coding mistakes. The pieces of code were brought in the session on a shared screen with the message: "this piece of code contains five coding mistakes. The one who finds them first, wins!" I will never forget all the eyes being fully focused on the screen and the joy of the team members when they correctly spotted a mistake. The senior developers didn’t tell who originally wrote the incorrect piece of code. This was not a blaming game, but a learning game. Because of their approach they managed to turn something negative (a mistake) into something challenging and fun, that resulted in increased code quality. The team was always looking forward to the next session!
As a Scrum Master I usually attended the code review meetings, but I did not have an active role. However, I fully supported the initiative and praised the team for their effort. I also informed others outside the team about our experiences with the code review meetings.
InfoQ: Which benefits did you get from the distributed approach for sprint reviews?
Alma: As all stakeholders were located in the Netherlands, it was very tempting to ask the Dutch team members to take care of the presentations and the conversation with the stakeholders. We realized though that we would somehow exclude the team members in India if we were to choose for that approach. Especially if you are far away from your stakeholders, it is important to stay in touch so that you continue to understand their desires first hand. A Sprint Review is also a good moment to celebrate success. All team members have the same responsibility for this success and so all team members should get the opportunity the share the success and be in the spotlight. I think we took this seriously and made sure that the distributed approach for the Sprint Reviews increased the sense of responsibility in the entire team.
InfoQ: If organizations want to develop products using a dispersed team, what advice can you give?
Alma: I would advise them to seriously consider the investments required to get the best out of dispersed teams. Are the results proving to be worth the investments? Don’t go for a dispersed approach simply to achieve cost reduction. Frequent travel, rework due to miscommunication and video conferencing tools are just a few examples of additional (high) costs that you have to take into account. Sometimes a dispersed approach is the only way to deliver a product, because the required skills are not available onsite. That may be a valid reason to develop products using a dispersed team. But still, if you wish to form high performing teams, delivering products with high customer value and with a short time to market, I believe an approach with dispersed teams is suboptimal. It’s up to the organizations to decide whether the suboptimal approach is optimal enough to deliver valuable results.
