1. You can turn Time difference into a boon: If planned and used well, you can make the time delay between the teams work as a boon. The availability window of the testing team during a day will be longer. Consider for example a test team in India and the onshore team in The Netherlands, the time difference is approximately 4 hours. This means that the test execution can go on for close to 13 hours in a day! You will have the defects found by offshore team are already in Defect Management System for onshore team to validate and discuss during defect meeting. You can have the offshore team retest defects in the morning and report the status of fixes at 9:00 A.M. CET. This helps you to set the priorities for activities for the day. To conclude, with proper planning, you will have fewer hours burnt in “wait-mode” and you are able to execute tests for more than 12 hours per day against a relatively low cost!
2. Sharpen your coordination: Many projects have issues with offshore test team as the onshore team lead does not have a clear view on the day-to-day activities of the team and resulting in lower confidence in the deliverables. To turn the table around, key thing for you as the test lead is to pay strong attention to the activity planning of offshore team members. Though the offshore test teams are usually well experienced with testing and have functional domain knowledge, the projects are controlled from onshore and hence you have to clearly specify the tasks and activities to perform. This has to be clearly communicated by you and managed daily. Remember that the more information you receive and share, the better the level of trust and confidence on the work performed.
3. Share the success and guard the responsibility: Always ensure that you give the offshore team due credit for the tasks performed. Since the team is not located close to you, it is even more challenging to keep them motivated and engaged in the assignment. More challenging is to gauge the level of motivation within the team. The essence of the point is to make sure that you provide the feedback about deliverables in a constructive manner and not personal. Since review comments are mostly provided in writing, it is wise to review it with an eye for the language and meaning that the comments can be interpreted as to avoid teams getting into unpleasant tug-of-war situations. In my projects, I make it a point to appreciate and thank the team members for support for all the activities constantly. I do not sugar-coat the improvement points, but ensure to give due credit to the things done well!
4. Have your contingency plan at hand: Keep an updated contingency plan for various situations like the activities that the offshore team can perform when the connection to onshore systems are not working, how to handle the timeline for test execution taking into account the possible risk of the connectivity issues etc. This will help manage the lost effort due to connection outages. I have a running list of nice-to-have things for the project and use items from this list as tasks during “wait-mode” for the team.
5. Watch out for “blame game” and focus on interpersonal relationships: Most common issue with onshore-offshore test teams working together is the blame game. When things go wrong, the teams start blaming each other for the issues. You must keep a close look out for this kind of attitude and fight it from the start: we are one team with one shared goal! This means that neither team (onshore or offshore) should be able to feel superior or inferior. Promoting an equal basis for responsibilities will encourage sharing of information and more productive teams. Stephen R. Covey says “A cardinal principle of Total Quality escapes too many managers: you cannot continuously improve interdependent systems and processes until you progressively perfect interdependent, interpersonal relationships.” Whenever I come across conflicts, I get everybody in the team on a call and ensure that the issue is discussed openly. This makes team members respect each other’s point of view and understand the mistakes instead of only blaming each other.

Though this article has been focused on leading offshore test teams, parts of the learning can be used to lead any offshore team. The key message for you as the lead at onshore is to plan with the above awareness and build your team that seamlessly works as one single entity, even though there are miles of physical separation.

While colleagues are worrying about leading remote teams, my experiences with the different offshore test teams make me want to do more of those assignments. Of course it was not a cake-walk in the beginning. I would like to share the first 5 tips, which I believe are the key ingredients for any test lead working with an offshore test team:

1. Know your team: It begins with not only knowing how to spell the name of the person, but also how you pronounce it. Though it might sound trivial to you, but it is indeed important to address people correctly by their name. In projects, I have encouraged team members onshore and offshore to create a simple one-slider with a picture and some basic information about them like ‘Field of Education’ and ‘Hobbies and Interest’, which helped to increase the bonding between the team members. This helps to attach a face to the person who sends mails or with whom you speak on the phone.
2. Tackle language barriers: Working with a team at a remote location means that your communication skills have to be strong and effective for the offshore team to understand you and vice-versa. It is important to take into account the level of English (which happens to be the most common working language with offshore teams) of the team members. In The Netherlands, at most clients, it is common to have Requirements and Functional Designs in Dutch. In the same context, test scenarios and scripts will be prepared by offshore teams in English and hence review by the business teams need to be planned with people who can read and write English. It is highly recommended to include having a Dutch speaking onshore person in your resource planning available to assist with the understanding of the scripts prepared to the business team. This is only to have a liaison in place to explain the right interpretation due to different language bases.
3. Plan pragmatic Onshore-Offshore %: Though a dream of many projects, 100% offshore testing is not realistic! More often Project Managers are engrossed in the cost reduction modes and find it easy to use offshore component as the quick way to achieve that theoretically. Instead of merely looking at the offshore % that you would like to achieve in your project to reach a target cost reduction, look at what is practically possible to offshore keeping the constraints of accessibility of the systems, complexity of the business processes, etc. In one of my project, we had to have representatives from 4 different systems sitting in the same room to finish the end-to-end process testing. This is typically something you cannot have the offshore team take part completely.
4. You need both – Issue AND Defect Management Processes and Systems: Most projects often have management tools to document and track defects as these support working with defects from both onshore and offshore locations. What many projects miss out however is having an Issue Management in place for resolving functional, technical or business related queries that the offshore team might have during test phases. Experience shows that this activity is often performed by sending around queries as emails by individual team members to onshore team or lead individually and are answered in that same manner. This process as you can see is error prone and is not effective as same questions are raised multiple times by different members. To make the process more effective, teams should use a web based document management system or project wikis to make it accessible to all team members. Remember: a tool will only help if the process of using it is effective. Hence, adapt an Issue Management Process that will work for your team setup and the choice of tool.
5. Managing your deliverables with Document Management: Work on a set of guidelines for document management for test scripts, test scenarios, test execution and test results documentation. Using a Test Management tool makes the task easier. Keep in mind the issues related to accessibility of these systems from different locations and the effectiveness of them when making a choice. It is important to invest time into a good Configuration Management document for specifically the test deliverables due to the offshore location of the test team. Prepare and agree on the templates that will be used for the various deliverables. I have found that checklists are indeed a good way to ensure coverage and also act as a quick self review for the authors of artifacts.

These 5 items reflect the knowledge and skills I have acquired with my experiences on how to lead offshore teams. Next week I shall follow on with the last 5 tips. What are your experiences with leading onshore-offshore teams? And which ingredients do you think are key when it comes to managing offshore teams effectively?

I look forward to reading your comments!