Many companies offshore the development of computer applications or supplement their software teams with remote developers. This arrangement can provide significant cost savings, but other factors must also be considered.

Common Issues

Having a distributed team means there is a physical separation between the remote individuals and the core business. At times this can lead to an emotional detachment. The results of this can surface in several ways ranging from remote employees feeling undervalued and forgotten about, to remote teams feeling less invested in the product and unempowered to make changes to drive the business forward.

In order to use the full potential of a remote team, it is necessary to make the team feel involved in the business from the start.

The decision to offshore

Sometimes the decision to employ remote developers is taken solely by management, and the core development team is left to fill in the details. However, to anticipate and minimise downstream problems, it is best if all internal parties are consulted at an early stage, and can agree to a plan before placing any external contracts for outsourcing.

Technical Specification

A technical specification containing all essential information relating to the offshore assignment should be prepared. This should clearly explain the activities and responsibilities of the participating parties. The content might include:

• An overview of the application, and definition of common goals
• Level of centralised control over design, configuration, and system architecture
• Security access permitted to each module, final assembled product, and production data
• Administrative procedures covering documentation, points of contact, team meetings, decision making, and official language (e.g: English)
• Team structure, qualifications and experience, composition and competencies
• Timelines and the project road map

Team Selection

A copy of the technical specification should be sent through commercial channels to each of the potential offshore teams. They should be asked to explain how they will meet the specification, provide details of their team picks, and identify any areas of concern.

Each response should be evaluated, and a decision taken on whether to drop a candidate team from the selection process or to move forward with a preliminary meeting.

The offshore team will normally be pre-selected by their own management to meet the requirements of the technical specification. However, in some cases, it may be necessary to handpick or interview offshore developers to meet a specialist requirement, such as cyber security.

The purpose of the first meeting is to build a rapport with the potential offshore team, to further assess their technical competencies related to the task, and confirm their ability to verbally communicate in the common language. The meeting agenda should therefore be designed to initiate appropriate conversations to help reach these conclusions. Topics covered could include the following areas:

Understanding the Task

• Some cultures have an emphasis on client satisfaction, so can be less eager to highlight areas that they don't understand. Rather than asking if the team understands something, try to evaluate their level of comprehension using a variety of techniques, such as Specification by Example or remote pair programming.

Specification by Example is a collaborative approach to defining requirements and business-oriented functional tests for software products based on capturing and illustrating requirements using realistic examples instead of abstract statements.

‐Goiko Adzic, Wikipedia

• Using this technique, different requirements can be defined in terms of inputs and can help determine what they think the outputs will be. This allows a scenario to be defined in term of inputs to the system, and each member of the team can be tasked to write down what the expected outputs might be. Answers can then be compared and discussed.

Communication

• If the agenda is clear, then the offshore team should be well prepared to answer any question in advance. If they are unprepared, then that might tell you something about their enthusiasm for the task.

• Whilst it may not always be necessary for every member of the offshore team to speak perfect English, the team leader and those filling a leadership role must be fully conversant. Be patient and allow everyone the opportunity to settle down and share ideas. Never openly comment on their standard of English.

Collaboration

Once a contract has been placed, the core and offshore teams have to learn to work together. Attention should be given to the following areas:

Timezones

• With flexible working practices and different time zones, it can be difficult to agree on a time-table of meetings that suits all parties.
• It may be best to avoid meetings during lunch periods, first thing in the morning, or last thing at night.

Problem Resolution

• If a problem arises, either party should be free to initiate a meeting as quickly as the time zones will permit. Skype can usually cover this requirement.
• When a large packet of work is due to start, consider having a kick off meeting with all teams in one location. Go through the technical specification and business requirements, and identify and resolve any areas of doubt or misunderstanding.
• Sometimes offshore teams cannot get access to staging or production environments. In this case, on site capacity will be needed to fix urgent issues.
• To reduce delays caused by broken builds, ensure that the re-deployment process is lightweight and fast so that defective code can be removed quickly, and without a large overhead.
• In order to encourage collaborative working practices, it may be a good idea to invite key members of the offshore team to visit and demonstrate their work in person. Problems can be discussed, information gathered on upcoming stories, and access allowed to the wider team and important stakeholders (if appropriate).
• Whilst the core team and the offshore team may work on the same code base, avoid sharing the same stories where possible. Splitting stories across geographical boundaries can result in duplication of work, whereas if each team in each location has ownership of their own stories, they can co-ordinate the build out locally, and deliver back the value without being blocked by the progress of another team in a different location.
• Keep a log of meetings and actions taken, and trust the teams to make the necessary changes they have committed to.

Conclusion

Spending time evaluating and picking the right team for a project tends to pay off in the long run. With distributed teams, the main challenge is usually communication. Having regular onsite visits can help the team members in different locations gel together. This makes it easier for people to reach out if they later need further information or explanation. Outside of meeting in person, video calls and regular status and story elaboration meetings help keep the teams working towards the common goal.

When onboarded, a project kick off meeting with all relevant employees in one location is invaluable to ensure the remote teams are fully engaged, and receiving the same information as those team members based on-site. Helping the remote team build their domain knowledge through requirement elaboration and product demos will help them contribute at the same level of quality as expected from someone who is committed to the company full time.

Above all, treat remote teams with as much respect as local teams, and empower them to suggest and deliver change, in order to help drive your business forward.