Overcoming Common Challenges with Offshore Development

It’s not a particularly well kept secret that there can be challenges organisations face when offshoring software development, both for greenfield builds and for products running in support and maintenance.

While the headline cost savings for organisations based in expensive locations can look particularly attractive, it’s important to understand the hidden costs and overheads involved in offloading a workload far afield.

Overlap in Working Hours

One of the most obvious challenges can be the overlap in working hours. Particularly when crossing several timezones, it’s possible to end up with only an hour or two a day of overlapping working hours. We’ve often observed customers on particularly early and late calls to coordinate work.

Some offshoring partners purport to alter their working hours to more closely match that of the customer. One thing to check here is that this applies to the whole team who will be delivering your application. There have been cases where the more seasoned team members work a regular local working day, with the more entry-level members manning the fort during the more unsociable local hours.

Tips:

• Ensure there’s at least a couple of hours overlap in regular working hours.
• Be aware that you will need to adapt your workflow to accommodate a small overlap in time.
• Consider favouring vendors in near timezones.

Increased Communication Overhead

A common source of day-to-day frustration can be the increased communication overhead, manifested both in poor means of communication (e.g. you can only talk to a team via a ticketing system) and language and cultural barriers.

Particularly for organisations that promote high-communication environments, effort is likely to be needed to discover processes and ways of working to promote good communication with off-shored teams.

Being aware of cultural differences and working with both teams to encourage a positive approach to embracing and learning from the cultural differences.

Tips:

• Ensure the vendor is comfortable using common communication tools.
• Ensure the vendor is able to provide a team with sufficient communication skills.
• Insist on meeting with the team who will be servicing you, rather than just the sales people.
• Be aware that communication is likely to have more barriers when compared to working with your local team.
• Look for ways to ‘bond’ the local and remote teams through more social activities. Consider things like remote code dojos.

Understanding the Domain

It’s important to not underestimate the value of domain knowledge in delivering software. Having engineers working in isolation of commercial objectives seldom leads to smart solutions that really deliver value back to the organisation.

Transferring knowledge of a business domain across a far-reaching organisational boundary can be particularly challenging. Accept it will take time for people to gain a good understanding of your domain, particularly if they’re not working hand-in-hand with your team.

Tips:

• Try to engage at a strategic level with any development partner. Work with them to ensure they understand the commercial problems you’re trying to solve.
• Take every opportunity to talk to people at all levels about your strategic and commercial goals. Avoid solution problems.
• Steer clear of ‘ticket factory’ type vendors who focus more on how quickly they can mark a request as resolved over understanding the business goal they’re solving.

Quality of Work

It’s certainly not a problem that’s isolated to offshore development – there are also plenty of nearshore vendors who offer dubious levels of quality in their software delivery. That said, quality is one of the most commonly cited problems with offshoring.

It’s important to understand the cause of the quality issues, whether they’re purely rooted in a vendor not having a team who is sufficiently mature in modern software delivery, or, as is often the case, it’s an upstream problem, perhaps rooted in poor communication and understanding.

Tips:

• Look for vendors who can demonstrate good credentials in modern software delivery practices such as Test-Driven Development and Continuous Delivery.
• Ensure you have sufficient skills to evaluate a vendor from an engineering perspective. Consider leveraging a trusted contact to help evaluate if you don’t have the skills in-house.
• If you experience quality issues, try to understand where they’re rooted. The root cause is not always in engineering capability.

Shared Understanding of Expectations

When crossing any organisational boundary, different expectations may exist for what ‘good’ looks like, particularly things such as quality, security, and user experience.

A common answer to this can be to try to document everything in very fine-grained detail, passing large specification documents over the boundary, which in-turn can have many knock-on effects to the speed of delivery, ownership, and subsequently quality.

Tips:

• Ensure expectations are well understood by looking to share values rather than large specification documents.
• Encourage teams to collaborate with one another, and work together to reach shared solutions.

Cost Savings not Easily Realised

With offshoring sometimes cutting local rates ten-fold, it provides some particularly compelling headline cost reductions.That said, it may be naive to assume that this cost saving will be directly realised. Strong software engineers bring far more to the table than just pure programming horsepower: engaging with stakeholders, interpreting commercial goals, improving software architectures etc. It’s hard to perform a direct day rate comparison.

It’s important to note that while day rates can provide a seemingly reasonable cost comparison, the output, both in quality and ultimately quantity can vary hugely between teams. We’ve observed offshore teams staffed with 40+ people delivering a comparable output to a team of perhaps 5-strong local team.

Particularly where day rates are much lower, it’s a sadly common pattern to see more bodies being thrown at an offshored software project to speed things up, something which has been shown to often have the opposite effect.

As well as eroding cost savings, this can also bring about many additional challenges that aggressively throwing people at a problem can bring.

Tips:

• Be sure the work is a good fit for offshoring. Some work that requires higher levels of interaction may not be easily achieved.
• Don’t be tempted to just throw people at a problem to speed things up.

Shared Engineering Values

Where local teams have strong engineering values, there can be challenges in sharing these values with remote teams. For example, local organisations who particularly value TDD, or a particular style of TDD, may be subject to frustrations when working with a remote team who don’t fully embrace a test-first workflow, or who have dramatically different styles.

Likewise for larger differences in approach to work. Teams who value releasing regularly, or working in small iterations, are likely to have tension with teams who don’t equally embrace Continuous Delivery and Agile workflows.

Even if a potential supplier promises that a remote team can work in whatever way the local team prefers, there is likely to be at best an onboarding process as the team learn different ways of working. Teams who are particularly mature at approaches such as Continuous Delivery have likely been finessing their craft and embedding their beliefs for a number of years.

Tips:

• Look for ways to align cultural and engineering values across the teams.
• Look to work with teams who come from a similar engineering viewpoint.

Ownership of Application Architecture

It can be disempowering for a team to have another team to dictate an architecture on them.

Without the team delivering the code being empowered to make architectural decisions, their engagement and feeling of ownership of what they’re delivering is likely to be lowered. When this is the case, you’re likely to observe a decrease in performance and quality.

Tips:

• Look to work with teams who are technically strong enough to own the architecture of what they’re delivering.
• Empower teams to own their end-to-end delivery.

Subservient Teams

We’ve often observed that the client/offshore supplier relationship can demonstrate result in the offshore supplier team becoming highly subservient.

This can be a dangerous situation. If the team who are delivering your software system aren’t able to have open and honest conversations, and are afraid to push a strong engineering agenda, it’s likely that undesirable architectural decisions will be made to appease seemingly immovable requirements.In the short team, some business folk may see it as desirable to work with a delivery team who don’t question anything.

However, this team is likely to be quietly accumulating technical debt under the hood, and may not be engaging to their full capacity if they’re not comfortable to ask challenging questions.

Tips:

• To keep an application’s codebase maintainable and in good health, it’s important to work with teams who are able to drive a strong engineering agenda.
• Look for teams who collaborate with the stakeholders, rather than blindly execute against requirements.

Demotivation of Local Team

We’ve seen cases where a local team who were initially hired for their engineering expertise have their role shifted to now effectively become Managers / Product Owners for an offshored development team.

Additionally, due to communication overheads, speed and quality of delivery, and an inability to enact change, we’ve observed wider local teams become frustrated when working with offshore partners. This can erode confidence in the organisation’s ability to delivery technology products, which can in turn lead to people seeking ways to bypass the organisation’s engineering capability.

Tips:

• Ensure people across the organisation who will be affected by a decision to offshore are bought in to, or at least understand the commercial strategy behind the decision.
• Be aware that many people’s roles may have additional overhead placed on them to make the offshoring partnership work.
• Keep a close eye on measures such as cycle time and internal satisfaction with engineering delivery.

Offshoring remains an attractive proposition, particularly for the headline cost savings. And there are certainly examples of organisations reaping benefits from offshoring part of their workload.

Some organisations who have made a real success from offshoring have built their own capability in a country with lower labour rates. This has allowed them to bring their own values in building the team, ensuring the primary challenges they’re dealing with are the communication overheads, rather than a lack of alignment.

For organisations to make a success in offshoring across organisational boundaries requires a strong evaluation process, perhaps involving moving a discrete piece of work as a trial, and a strong commitment to invest in the longer term to continue to nurture and grow the relationship with the remote team.

About the Author