SDG Blog, November 15, 2012 By Jeff Ortman (http://solutiondesign.com/successful-offshore-development-practices/)

Offshore development has become a standard practice in many organizations. There has been much written about how to successfully initiate and manage offshore development. Detailed process models have been developed both by onshore and offshore companies to guide organizations implementing offshore development. Most of these process models detail a rigorous approach to software development with the production of lots of requirement, architecture and design documentation. These processes are all designed to make sure that the offshore group knows what to develop.

Agile software development processes were not thought to be able to work with offshore development because of the extremely high level of communication required in agile practices and the emphasis on physical proximity and face-to-face communication. Martin Fowler wrote one of the early articles on making agile and offshore development work together, and it can be found here. He stresses practices that can be followed to make agile and offshore development work instead of processes. This article has become a classic and many others have added to his original thoughts.

I have worked on multiple teams where most of the software is developed and maintained offshore. I have been on both successful and unsuccessful projects, but I will not address here the advantages and disadvantages of offshore development and whether or not a company should decide to invest in it. Instead it is assumed that a company has already implemented, or is thinking about implementing, offshore development.

I have provided some ideas on specific practices to follow that can help increase the likelihood of a successful offshore development project. These practices can be used in both agile and non-agile environments. It should be noted that these practices have a precondition that the offshore team has knowledgeable and talented developers. If an offshore team is filled with junior and not very talented developers, offshore development will fail, plain and simple.

1. Full-time onshore technical team lead:
   The biggest mistake that companies make is assuming that someone can manage offshore development in their “free time” between their other responsibilities. This is a recipe for disaster. There must be a full-time onshore technical team lead whose sole job is to work with the offshore team. This team lead should explain the business priorities and motivations for each project or enhancement, help give technical direction, establish coding standards and practices, help solve difficult technical challenges, review code and help train and mentor the offshore team. This is a full-time job, no different than a team lead working with an onshore team.
2. Corresponding offshore technical team lead:
   The onshore team lead should work with a corresponding offshore team lead. The offshore team lead should be empowered to make technical decisions. This prevents the onshore team lead from becoming a bottleneck. Offshore developers, especially more junior developers, can go to the offshore team lead with technical questions. If the offshore team lead doesn’t know the answer, he/she should ask the onshore team lead. It also gives the onshore team lead one primary point of contact for status and all other communication.
3. Daily meetings using videoconferencing:
   The onshore and offshore team leads should have a quick status meeting every day. Other meetings should occur as necessary, and all should be done using web videoconferencing software. Using video conferencing allows an onshore team lead to see the body language of the offshore team lead. Confusion or frustration can be sensed on a videoconference but might be missed by e-mail or on a chat session.
4. Get to know all offshore developers:
   The onshore team lead should talk to all offshore developers, not just the offshore team lead. This communication is more infrequent, probably about once a week instead of every day, and should also occur using videoconferencing. This practice assumes that all developers speak adequate English, which may not be the case on every offshore development team (although it should be for effective communication). Often times, talking directly to a developer offshore can reveal issues earlier rather than later. The offshore team lead may inadvertently or intentionally downplay a potential problem that can be discovered by talking to individual offshore developers.
5. Small, highly skilled teams:
   A small team of very highly skilled offshore developers will be more effective than a larger team of average developers. If the offshore team becomes more than 6 or 7 in size, the offshore team should be split into multiple teams and each team should have a different onshore team lead.
6. Everyone participates in architecture and design:
   The offshore team should participate in architecture and design discussions, although ultimately the architecture and design decisions should rest with the onshore team. The architecture and design should not just be thrown “over the wall” to the offshore team. In an agile environment, this will likely involve many team members. In a more traditional software development environment, just the onshore and offshore technical leaders may meet. It will help the offshore developers to understand the decisions that are made if they are part of the design process. It will also help the offshore team grow in their experience, increase retention and job satisfaction and ultimately lead to better code and a better product.
7. Challenge offshore developers:
   All developers like to be challenged, and offshore developers are no different. I have had ideas for designs in my head, but have asked the offshore team to come up with their own design or ideas on how to solve a problem. Many times they have come up with a better solution. Offshore developers should also be encouraged to push back and present their own ideas for a design or how to solve a specific problem. You know you have a good offshore team when they look at your idea and are able to come up with a better one. In addition, offshore developers will tend to want to stay on the project and contribute more if they are challenged and feel like they are helping with the difficult and key technical problems faced by the organization.

Developing software with a team half a world away and in a different time zone is very challenging. There are many problems to overcome to have a successful offshore development team, and not all problems are addressed by these practices. In addition, not all of the practices outlined above will be feasible to implement in every company. If you are currently doing offshore development, then hopefully some, if not all, of the practices outlined here can help make offshore development a little easier to manage and lead to more successful projects.