Where should I outsource my agile developments - onshore, nearshore or offshore?

I was recently at the Agile awards in London where I hosted a panel discussion. One of the panelists was Carl Bruiners. He is an agile software development consultant and currently works at furniture retailer Dunelm. I asked him where is the best place to outsource agile development – onshore, offshore or nearshore?

I am using some of Carl’s comments in an anaysis I am currently writing but thought I would share his comments as I know he is answering a question many people want answers to.

This is what he said:

“Working in an Agile framework does challenge the practice of offshoring, though often I have found in various organisations the decision to offshore to low cost regions is often not the choice of the companies IT function, but the choice of the finance department.

To challenge this I would recommend engaging with the executive to explain the cost of ownership / value return, as it is often narrow sighted not to consider the other factors you inherit when offshoring; language difficulties, communication latency, culture, etc…

At GE an individual (offshore) engineer was a third of the cost of an engineer based in Cambridge, UK, but the Cambridge engineer was 4 times more productive and therefore far cheaper per feature delivered.

In practice I have never found there to be a big difference between onshore, nearshore or offshore. Whilst at GE and Lloyds I had teams based in Cambridge / London and ones based in India. At Dunelm I have teams in Leicester and London, yet the communication challenges remain the same as those at GE and Lloyds. If you have separated your delivery capability you need to ensure that you leverage as much as possible on the various communication / collaboration tools available (instant messaging, video conference, Interactive whiteboards) to try to bridge the physical gap between teams.

One critical element to consider when creating remote delivery capability is not to split the team between two locations but to create discreet teams in each geographic location to deliver features. For example when I arrived at GE an Agile team could consist of two developers in Cambridge UK and two developers Hyderabad, India, this created numerous problems; communication latency (even effective stand ups become a challenge), effective pair programming was virtually impossible. The first thing that I did was reshape our backlog into Feature releases and formed discrete Agile teams in India and Cambridge so that each team would deliver a feature in its entirety. This improved our effectiveness as team communication issues were localised and the behaviors of the teams improved as each team felt more inclusive of delivering a great product.

I would also analyse the maturity of your Agile practices. At Dunelm we have two teams in Leicester and two in London. We have implemented test automation (BDD) and Continuous Integration (soon to have Continuous Delivery) to ensure the quality of the product and ensure the feedback loop is quick and transparent to all the teams working on the product. It becomes a far more difficult challenge to maintain multiple teams within the same building without these techniques and virtually impossible to maintain a sustainable remote function if Test Automation and Continuous Integration is not in place.

My top five recommendations would be;

Don’t have remote teams unless you really need to
Have teams within the same time zone
Implement Test Automation
Implement Continuous Integration
Create a backlog of work you can deliver as independent features”