Reading:
Community Stories: Collaborating With Distributed Teams on Culture Transformation and Good Practices
Share:

Community Stories: Collaborating With Distributed Teams on Culture Transformation and Good Practices

Read "Community Stories: Collaborating With Distributed Teams on Culture Transformation and Good Practices" from our Community Stories

By Iram Arshad

I am virtually connected with a distributed team where some of the teams are in the same region and the rest of the members are in other countries. For instance, some of the front-end and back-end teams are in the same region and some are in other countries (i.e., USA) and they all work together by connecting via different communication channels. Despite team size, good collaboration, and healthy environment, working with a distributed team is very challenging and tedious due to time zone differences, virtually managing the work and ensuring the quality of the product. Working as a Senior Software Quality Assurance Engineer for five and a half years until now gives me the best opportunity to observe the most day to day challenges that are found in teams. These issues fall into overarching themes of communication, collaboration and physical constraints. However, these challenges can be mitigated with proper planning and with the motivation of can-do commitment attitude, across the teams. Let's take a look at those challenges and some ways to overcome them that I have learnt.

Key Challenges of Working With Distributed Teams

We all are facing day-to-day challenges or problems in our jobs. To tackle such situations we come up with solutions. To help the community,  I’ve noted the key challenges I’ve faced when  working with a distributed team.  

Communication Challenges

If we think about prioritising team problems and challenges, then communication comes out top, as it can be at the heart of every problem.  Needless to say, communication is the key point of every successful project. According to Grace:

“47% of failed projects are linked to requirements management. Within these failed projects, 75% reported that poor communication led to misplanned requirements[1]”. 

There are various strands to communication and challenges in how we communicate.

  • No status meeting: It is one of the most common communication challenges we have to face during our work. For instance, In our case, we were not following status meetings in day to day practices. This resulted in creating a gap and gave the impression that we weren’t putting any effort to make the product right.  

  • Planning and goal setting: It is a critical part of accomplishing your objectives. According to Dye, L. D. (2010): 

“Goal setting and achievement thinking—the key to project and professional success[2].”

As every team member was working independently with the distributed connected members in such a way to only focus on specific tasks that had been assigned by the distributed manager.  Furthermore, resources were not actively participated in resolved the gap and any indifferences.  In addition, In case of faced issues and delay in release, only blaming games rather than come up with a better plan or a solution. 

  • Clear understanding of issues: The most overlooked challenge was clear understanding issues. For example, when one of the team members was demoing a task, they learnt that there was an understanding issue and it was not implemented as it was communicated. 

Collaboration Issues

Not only were there communication issues, but we also faced challenges around collaborating as a team.

  • Behaviour issues When the team were not actively participating in assigned activities they did not consider themselves to be working as a team. For example, if the team were only focused on a specific  assigned task or if no task had been assigned to them they wouldn't ask for other tasks to take on.  In addition, they were not actively involved in activities such as sprint planning, retrospective meeting, demo and so on which were organized by distributed members

  • Defensive behaviour and not working as a team: If a project was delivered successfully then it was a team success but if it fails then it should be considered as a team responsibility. But this was not the case, for example, if a release had not gone well then without identifying the problems, all the blame shifted to one side of the team. In my opinion, this is not a good approach. It really had a negative impact on the team and sometimes resulted in job dissatisfaction and resignations going  up.  

  • Lack of team participation:  If there is no active participation from members then there can be a difference in expectations versus reality.  Our client expectations were that the offshore team should come up with plans and solutions to improve product quality. Unfortunately, in reality, our internal team, specifically QA, was not actively involved in any ongoing process so without following any QA practices and standard their only focus was to test and verify the assigned tickets. 

Physical Constraints

Additionally, we also faced some physical constraints as well. These constraints can be broken down into time differences and cultural differences.

  • Time differences: Nevertheless, the time difference is one of the physical constraint issues we have faced during our work. Such as you have a work delay in such a way to wait for the response of your query and then your work put on to the next day. The same thing happened to us. We were connected virtually with the time difference of GMT-5 (i.e., an organization that is 10 hours behind us). If we have encountered any issue(s) that need to be fixed urgently then we have to wait for the end of our day to communicate with the other team. 

  • Cultural differences: Another constraint we have faced is cultural differences (holidays and language barriers). These issues lead toward behavioural issues which we have mentioned above as well. For instance, as in some cultures, people talk to each other they give space, while in other cultures, they stand alone. These issues should be recognized in case of avoiding barriers ineffective communication. 

Solution & General Practices

After having done external and internal meetings activities we tried to mitigate the problems by identifying the root cause of them and came up with two plans.

In the result of the external meeting, with co-located managers, we summarized that most of the time co-located team complained that they had no proper communication with remote team members and they didn’t know what the contribution of a remote team was to the project or how their participation was improving the quality of the product. From the internal meeting, we identified the root causes which are listed and described above as key challenges. 

By doing these meetings and analyzing the root cause problems from both sides we came up with some strategies and general practices which we have implemented in our team. We named these plans as external and internal plans. Furthermore, we emphasised the need to develop new habits across the teams. 

External and Internal Plan Execution:

Involvement in the Hiring Process:

To overcome the impact of candidate competence, first of all, we involved our distributed team managers in the hiring process and tried to bridge the gap by adopting this solution. The step was adopted to comfort the client about the resource skill set and build up the trust level on resources. 

Internal QA Processes: 

To handle the internal challenges we decided to implement standard QA processes as well as to share it with the across team managers. 

For this purpose, we have come up with an Internal QA Process and after presenting these activities to the external managers, rolled out the activities across the team. We improved our internal process with the following steps to overcome the gaps between teams: 

  1. Common test case writing tools were used across the teams 
  2. Sanity, Smoke and regression suite execution on a daily basis based on needs 
  3. Daily standup with the onshore team through Zoom and Slack 
  4. Started weekly manager meetings and discussion on weekly tasks 
  5. Implement QA activities in our daily routine and make sure that onshore and offshore both are following it 
  6. Involvement in sprint planning, demo and retrospective meetings 
  7. Every month we had a QA meet-up across the team

Solving Our Key Challenges

To mitigate the above mentioned key challenges we proposed the following solutions:  

Communication Challenges

We decided to hire an external trainer to train our resources as well and, with the help of the trainer, prepared individual progress reports to see the level of every team member so that we can work with them further and utilize them accordingly. To handle behavioural issues, we focused on implementing the internal QA processes. For resolving time differences and understanding issues we decided to plan team meetings on alternative days. More and more interaction in the team helped resolve the understanding issues and gaps. 

Status Meetings

To overcome this challenge, We ensured that every team should be responsible for their given daily status through any of the communication channels (i.e., Slack, Skype, Email, Zoom) or by attending daily standup calls.

Planning and Goal Setting

Previously, QA resources were not engaged in any planning and goal setting. We requested our remote team to make sure every team member participated  in planning and goal setting. For this purpose, we set calendar invites so that teams could adjust their work according to their scheduled time.

Defensive Behaviour and Not Working as a Team

To resolve this problem we started a team lunch every month as well as internal team QA meet up. We started appreciating the efforts of team members by announcing the “star of the month” and as a reward gave them a certificate and prize amount. 

Lack of Team Participation

We decided to group our team and assign them specific topics to be worked on. Where every senior would train a junior resource and come up with the presentation. For example, we created load testing, security testing, API testing and automation testing groups and categorized the teams so that they can learn and grow as well.
Moreover, we came up with some common practices across the team and emphasized implementing these practices as well.

Time Differences and Other Physical Issues

We decided to hire some of the support team at night to resolve the time difference issue. For each project, we hired night shift support in case of an emergency. Moreover, every year some of the team members would flyover to meet distributed team members to get to know about each other in a better way.

Five common good practices across the team 

Last but not least our strategy was to develop some common practices across the team to mitigate the challenges and to make sure that we have good enough coverage for the problems.

  1. Strong communication: It is an essential part of QA Jobs to have strong  communication across channels
  2. Innovative: Come up with new ideas to improve the current process. There is always room for improvement so be willing to propose new solutions across the teams. 
  3. Continuous testing: In agile having only one person know what to do this is the biggest bottleneck for promoting continuous testing. Give early feedback and ensure that everyone in the team is responsible for quality.
  4. Knowledge sharing session: Hole a monthly knowledge sharing session to ensure that employees are aware of new technology stacks as well as learning new things. 
  5. One unit team: In an agile environment, Tom & Jerry fights are discouraged between QA and Devs. It’s an era of QA and Dev collaboration so consider all the team either virtually connected or not as one unit. In particular, work as a one unit team and not as competitors because in the end the quality of product matters.  

How Did It Go?

We have implemented the above-proposed solutions in our organisation and have followed our Internal and External plans and we have started seeing the  benefit after eight months. We firstly executed this plan in one of our maintenance products. In maintenance, we release every two months. After following our plans and delivering a successful release, our QA team was appreciated by the onshore team because of our testing before pre-deployment resulted in only 2 issues. So this experiment worked for us and we decided to roll out these plans to other projects as well.  

Some other benefits we noticed after following these points were:

  1. Our team started to grow and the people leaving the team decreased as employees now feel valued by managers and team leads 
  2. Job satisfaction has increased
  3. The onshore team are taking an interest in our activities and welcome our suggestions 
  4. We’re now moving forward with the automation of the product and now many of our products are in the automation stage

By following these practices both on-shore and off-shore teams are working as one unit regardless of time zone and distance. We are on the right track to achieve our common goals and our QA team has grown in strength from three to four to more than twenty and we hope to expand continuously. 

Author Bio:

Iram Arshad is an experienced senior software quality assurance engineer with a good understanding of software quality assurance processes. She has hands-on experience in the design and development of automation frameworks in selenium web driver and Cypress end to end for enterprise-level applications. Furthermore, she has extensive experience in load testing of different applications as well. Her mission is to interact with the global community of testers and come up with the solutions to contribute to the field of software testing. Her interests include exploring different tools (i.e., Jmeter, LoadRunner, cypress etc), reading research papers specifically relevant to testing and recently writing the articles for Dojo. You can find her via Twitter and Linkedin. 

References:

1. Tackle-poor-project-communication by Grace Windsor
2. Goal-setting-achievement-thinking by Dye, Lowell D
 

To BDD or Not to BDD That is The Question
The MoTrix - Leading Communities of Practice with Drew Pontikis
Using Data to Drive Testing Decisions
With a combination of SAST, SCA, and QA, we help developers identify vulnerabilities in applications and remediate them rapidly. Get your free trial today!
Explore MoT
TestBash Brighton 2024
Thu, 12 Sep 2024, 9:00 AM
We’re shaking things up and bringing TestBash back to Brighton on September 12th and 13th, 2024.
Cognitive Biases In Software Testing
Learn how to recognise cognitive biases, explain what they are and use them to your advantage in your testing