Offshoring agile software development in Asia

An important step in scaling Aconex was when we extended our engineering capacity with a second development centre in Bangalore starting from around 2011. Bruce Taylor led our team there from 2012 and has written a great blog post on what we learnt setting up the operation.

For Aconex, our primary goal in establishing the Bangalore office was primarily to scale the development team. We had also identified some modest cost benefits, but these were secondary. While many software companies move development offshore to reduce cost, we found that building, developing and retaining a high-performing team (and the necessary additional management overhead in the ‘home’ office) meant that any savings were limited.

In our case, after looking at alternatives such as outsourcing to a local provider, we decided to employ our team directly. Over time, it grew to more than 100 people and was a core Aconex office.

Building the centre in Bangalore supported our growth by giving access to talent that was not easily available in Melbourne at the time. Our Australia-based development function continued to grow but we simply couldn’t hire the developers we needed fast enough in the local market.

In his blog, Bruce provides insights, from the Aconex experience, into both recruitment and team development, supplemented with research based on consultation with other companies.

Overall, the result for Aconex was very positive. Bruce and our Bangalore leadership group successfully established a highly skilled agile development capability, consisting of multiple scrum teams fully integrated into our Melbourne product and engineering operations. The team led several of our main product development streams, particularly across our mobile product set. We successfully aligned the Bangalore office to the Aconex company culture, while recognising and embracing the local culture and customs.

While most people worked in product and engineering, and this remained the focus of the office, we took advantage of the infrastructure there to relocate our Middle East helpdesk, and to add some other roles, all working closely within their respective global teams.

Bruce has shared several factors that helped make the offshoring successful:

• Be prepared to offshore meaningful work. Giving teams ownership of entire products or modules recognises their abilities and allows them to develop their skills.

• Aim to build English-speaking teams. Remote communication can be hard enough. Why make it harder if you can avoid introducing a language barrier?

• Train your recruiters. Hiring and retaining talent in a city like Bangalore is tough. Wherever your recruiters are based, make sure they have sufficient knowledge of the local job market and culture, and are crystal clear on the hard and soft skills you are looking for.

• Don’t rush the hiring. Recruit for cultural fit as well as technical skills.

• Headhunt your key people. You are likely to build (and define) a team from the top down, so invest extra effort on the first, critical hires.

• Align processes across your local and offshore development teams as much as possible. For example, consider using a consultancy to set up your agile development environment on a build, own, transfer (BOT) basis.

• Put local (home office) people in for extended durations at the beginning. You are likely to have team leaders or managers from head office running the overseas development teams until they are well established. It is preferable to have one or more of these people on the ground for a year or two if you can.

• Continually train your team. In India, as in many developing countries, candidates and staff place a huge premium on learning. Be purposeful in thinking about the workplace as a kind of Tech university, where learning on the job is recognised and prioritised rather than a side benefit of employment. The return, measured in employee upskilling and loyalty, will be worth the effort.

In addition to the strategy, Bruce details plenty of tactical ‘hacks’ that we learned along the way. For example, when hiring in India we would have a high rate of no-shows – candidates who had accepted an offer but didn’t show up on the first day. Apparently, that is quite common. Recognising, this we moved to hiring two people for every open position, ensuring that we had coverage and we didn’t mind being ahead of our hiring curve if all the candidates started.

I’ll leave the rest to Bruce. You can read about his experiences here.