Working with overseas teams can be both interesting and challenging. On the one hand, you get to learn about different customs and how other teams approach problems, but on the other hand, you need to deal with time differences and misunderstandings. We’ve worked with overseas teams in various capacities, from overseas teams within the same organization to out-sourcing work to independent contractors. For this article, we’d like to focus on what we’ve learned when out-sourcing development work, using agile methodologies, to a third-party overseas team.
Outsourcing development work may seem like a less expensive option compared to hiring local developers. However it may not be the cost savings you initially believe, once you add up the additional communication and measures that must be taken to work together effectively. Experience working with overseas teams is critical to improving your methods of communication with them. We’ve highlighted the three items we believe are most important below:
1. Well-defined requirements
2. Frequent meetings and retrospectives
3. Specific schedule
Your overseas team typically does not attend all the meetings and discussions regarding requirements and expectations. As a result, they rely on the documents and user stories you provide them to determine what they will be implementing. We believe that the best sign that you provided the correct requirements is based on the software that you receive at the end of each iteration. If you get back what you expect, then your requirements were detailed enough. If you don’t, you need to add more information next time. When writing stories for overseas development we always make sure the stories are highly detailed. This includes:
– A description of why this story is required
– The acceptance criteria for the story, including any boundary conditions
– Walk-throughs outlining how the user will use the feature implemented in this story
– Sample test cases
– Mockups and screen-shots
– Videos or pictures
We put extra effort into making sure that all of the items above have specific requirements and try to put myself in the overseas team’s shoes to make sure they have everything they need to implement the story as expected.
Frequent meetings and retrospectives
If possible, we like to have regular conference calls and retrospectives with the overseas team. This can speed up the process of any questions that they may have regarding the project. We also believe it brings your local team closer to the overseas team to make everyone feel they are working towards a common goal. Retrospectives are also important, as time zone, location, and cultural differences may cause the overseas team to feel like they have little input. It’s important to give that team a voice and to adjust the project based on their feedback, in order to deliver the best possible solution and to continue working well together in the future.
A specific schedule can reduce confusion on the team. If you expect that your iterations are two weeks in length and will be fully tested by the overseas team by the last day of the iteration, this must be communicated in the scheduled. Schedules must also indicate times in specific time zones. Many teams assume that an end-of-day due date may mean they have the evening to complete it. However, depending on time zones, one team member’s evening may be another’s morning. Coming into the office ready to work only to find out the other team has not completed their task can push the project timelines back. Specific schedules also highlight expectations and when milestones are expected to be achieved. By sharing the overall project schedule with the overseas team, they will have a better understanding the impact of a late delivery.