Distributed development depends on effective communication: you need to look for ways to have robust and diverse communication, build empathy towards each other to encourage feedback, and keep an eye on motivation, said Abby Bangser and Bhagya Perera. Team members are more engaged and creative when there’s shared ownership and responsibility for complete delivery from idea to production in distributed teams.
Abby Bangser, Quality Analyst with ThoughtWorks, and Bhagya Perera, Senior Test Analyst at Reed Business Information, spoke about insights into distributed development at the European Testing Conference 2017. InfoQ is covering the conference with Q&As, summaries and articles.
InfoQ interviewed Abby Bangser and Bhagya Perera about the main challenges in distributed development and how organizations can deal with those challenges, how to improve collaboration and communication in distributed teams, how distributed working affects teams, and how to leverage the benefits of both onsite and remote testing.
InfoQ: What are the main challenges in distributed development?
Bhagya Perera: Absolutely communication first and foremost. Teams tend to "forget" or "ignore" the team away from them when it comes to discussions, which can lead to confusion and demotivation. Cultural differences, time zones, and different tools can also play a big role. In a more specific example, we have even had challenges with connectivity to specific domains due to security rules.
Abby Bangser: I agree that communication is the baseline for all other challenges. Building trusting relationships while not in person can be really challenging and that can impact the ease of collaboration. I would also add that it is important to keep an eye on motivation for the people who are not co-located with the business. The trap of sending "easier" work (which is often not even easier) to them can really demotivate team members.
InfoQ: How can organizations deal with those challenges?
Bangser: Like anything else, being aware of the challenge and having open discussions is the first step. I have found that when every team member has shared ownership and responsibility for complete delivery from idea to production, they are more engaged and creative when solving communication challenges. One easy way to do this is to split work by feature rather than by activity.
Perera: The success of distribution is mostly up to the team and their drive to communicate more with each other. Not only about the daily work, but reviewing basic needs like connectivity, comms clarity, and even discussions around requirements and estimations across teams. Building empathy towards each other will encourage feedback from the distant teams which will mean issues are worked on actively when pointed out.
InfoQ: What suggestions do you have for improving communication and collaboration in distributed teams?
Perera: Identifying what communication issues the teams has is a good start. Be open about it and discuss the issues with the intention of solving it. Get to know the team better. About their culture and their backgrounds. Learn how to give feedback. Not only the negative but the positive as well. Build empathy. Share interests. Build relationship outside work which will help to build trust. There are so many things you can do if you start listening.
Bangser: Firstly, I would start to identify the different types of communication you have between your onsite team members. You may identify that you have formal meetings around expectations, informal brainstorms, whiteboard sessions, social jokes around what you did last night, and maybe others. Then I would suggest thinking about how you communicate with the team members not in your same office. You may find that you only have some of these. And most likely they revolve around the formal meetings style (and maybe a few informal IRC based chats). Ways to increase the other communication styles is to find tools that support them. Maybe video conferencing with an extra camera pointed towards a white board, maybe a "coffee break" chanel on your chat tool with a daily joke or quiz question. Look for ways to have as robust and diverse communication across locations as you do when in person.
InfoQ: What development activities are most affected when teams are distributed?
Perera: I personally believe that any activity you handover to a distributed team- not just testing- will add an extra level of complexity. All the challenges discussed in the first question will rise and distributed teams can feel left out. If any of the project activities are done in only one location, the information availability will make the team function smoother than in a distributed team where you need to actively share information. Specially the tacit knowledge within the team. Successful distribution of the team will encourage more documentation, more discussions and more dependency. All depends on effective communication.
Bangser: While communication can be more challenging across time zones, accents and cultures, I find that it is not always acknowledged how hard it is in person. Some of the distributed teams I have been on have done the best job of identifying and rectifying gaps in communication through more explicit examples, more regularly used and updated documentation, and more active awareness of sharing daily successes and challenges. One activity that is particularly negatively impacted is the "hallway conversation". The eureka moments that can be created through random conversations are hard to recreate and I wish I had a better solution to support those.
InfoQ: How can we leverage the benefits of both onsite and remote testing?
Perera: I would like to see distributed team members as one team. Which it is. As soon as we bring the division of onsite and distributed the complexity begins. Diversity always brings different experiences and ideas which makes the products successful. But time zone differences and language differences can frustrates each other and that can affect the overall quality. I personally like distributed testing because of the experience the remote teams often have. They can rotate between different clients and that mean they are exposed to issues, technologies and process that we can learn from. But onsite testers have the advantage of building up conversations with people who indirectly contribute to the product and build different test ideas.
Bangser: If we define testing as the generation of new understanding around a product, it is clearly beneficial to value inputs from both onsite and distributed team members. I prefer to see entire features analysed, designed, implemented and verified with a group of people who can communicate easily, and therefore operate very much like a co-located team. If you do find yourself in a team that is split by activity (development in one location, testing in another), I would suggest identifying what quality based activities the team values and wants to leverage, then split those based on who can be most successful in those activities. Leveraging the "black box" style of testing by the distributed team member who may not have been included in all the decisions around a new feature can be very valuable.