Doing Offshore Development: My Key Success Factors

A little over two years ago, I took on the endeavor of offshoring development of my software project.  This was something new to me, from an execution point of view.  As I embarked on the process of engaging an offshore team, I got a lot of advice from colleagues.  Some of it was even solicited by me (rim shot).  To be sure, much has been written and said about this topic, but here are my key learnings that hopefully will help you as you start down the offshore path to software development.

Cost Savings Should Not Be Expected Early

Many firms go into this with an expectation that development costs will go down between 50 and 65% right away after deciding to do offshore.  This is an unrealistic expectation that needs to be managed.  My research revealed that it takes 1-2 years to fully integrate and optimize an offshore team into the local team.  In the interim, there are many hurdles to overcome such as language, cultural differences, understanding individual contributor technical expertise, shared understanding of the software process used and the like.  Overall, expect productivity to go down and costs to actually rise in the first 6-9 months (I think team size is the big variable here – Mythical Man Month rules apply) while the team figures out how to work together effectively.

Recognize That Optimizing Offshore Development Is a Journey

In my experience, integrating offshore is an exercise in maturing overall team performance.  It’s really no different than working with a team that sits in your midst.  Mistakes will be made, miscommunications happen and you get some downright bad results early on.  It may seem like nothing is happening because you can’t see people working on your software project.  In my experience, I had to manage the local offshore team’s expectations more than anything.  They had to adjust to working with colleagues who they perceived were not as strong technically.  My team early on overcompensated for what they saw to be as poor results.  This type of behavior actually proved to be counter-productive to the development of an overall working relationship and software engineering process.

My recommendation:  keep the process as simple and clear as possible and build upon successes.  At some point, you as the leader will need to inspire another evolution of process as the team matures.  There will always be room for improvement.  Don’t try to do it all at once.  We try to infuse internal process improvements into each development iteration to drive the most urgent improvement opportunities.

Agile Process Is The Way

In an offshore development model, I have come to embrace Agile as the only way to develop quality software.  We use the Scrum brand of Agile and I found that with two-week sprints I was able to frequently provide feedback and check in on progress.  I observed how the team interacted with each other, which people seemed to consistently step forward in sprint reviews and planning sessions as well as probing deeper on process improvements.  When there are gaps, I could provide advice and direction on what needed to change.  I also used these as opportunities to form opinions on which team members were top contributors and which were at the bottom.  In partnership with my offshore partner, we were able to replace the lower performers quickly and increase team effectiveness. 

HD Video Teleconferencing Equipment

The best technology investment I made was to outfit our team scrum room with high-definition video teleconferencing capabilities.  I vividly recall the day we enabled the system — it was so cool to see the people we are working with live and in person.  It didn’t take more than a few days for the programmers on both ends to get used to using the equipment — the daily scrums were much more compelling in HD video!  It seemed like the table became one, longer table that everyone sat around.  The names became people that we could talk to and laugh with even though we are a world apart geographically.  Picking up on non-verbal cues really helped.

Let’s face it, building software with a geographically dispursed team is really hard.  I don’t think you can get around it.  But, I hope these few ideas I have based on my lessons learned can help you create conditions on which to build successful software projects.  It is a journey indeed.


Published by


I am a software lab manager in the Corporate Research Lab at 3M in St. Paul.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s