Making offshore development work

Offshore development is pretty common these days, but well-performing offshore teams are less so. But it doesn’t have to be like this.

Whilst remote development, particularly across time zones, brings unique challenges, close management of information, team cohesiveness, and some patience and perseverance are usually enough to overcome them.

As a general principle, build the system around the people doing the work. Seek to understand the offshore developers and accommodate their needs as best as possible. Avoid the temptation to impose local processes without first assessing their suitability.

Consider which operating model may work best, ideally in collaboration with the remote team, onshore staff and anyone else impacted. A couple of popular offshoring approaches are as follows.

The remote team may work similar hours to the local business day, allowing them to be an extension of the local workforce. Active engagement and good communication between both sides allow more intensive ways of working, such as a local Product Owner-led Scrum team.

Alternatively, many offshore teams perform well when they are responsible for the end-to-end work rather than bouncing part-finished work back & forth between distributed teams, avoiding the need to collaborate, reducing decision latency and promoting maximum workflow.

Importantly, the remote team (and their supplier, if present) must have bought into the chosen approach and be working with you rather than against you. Have at least one ‘translator’ with a foot in both cultures and try to meet up in real life at least once to develop some human relationships.

Asynchronous communication becomes necessary if you don’t want people held up when working across time zones. Effective written communication in a shared language will be required.

If you are unhappy with your development team, they may need more detailed guidance.

Better software requirements can help with this.