Agile Outsourcing, from Idea to tested Software

Archive for September, 2009

Offshoring, near sourcing or local sourcing and how to fit agile 07 Sep 09

1 Comment »

“Should you outsource software development” is a very hotly contested topic on the Internet. And again you have to whole spectrum of opinions, from the “we are all going to loose our job” blog posts to the “we can develop everything at any time at the best rate for you” emails. Reality is that offshoring, near sourcing or using local or even in-house developers are all viable solution in some circumstances. Fact is that you will get a lot more man-hours if you choose to use a lower cost destination. Whether this is going to save you any money is an entirely different question.


The deciding factors for us to outsource the development were the following:

  • Lack of local Ruby on Rails expertise
  • Limited financial resources and the price was right
  • We have developed software before
  • We develop alongside them and can see their code
  • Due diligence finding an offshore partner (see three part post about our search)
  • Matching our developemnt process with theirs
  • Solid list of requirements


We can gladly say that for us it worked very well, we got a lot more bang for the buck than if we would have developed here. Here are the key points that we think were crucial to our success:

  • We felt comfortable with the company we chose from the start
  • We felt especially comfortable with the team lead, a highly skilled software engineer with excellent communication skills
  • Skype was available at any time for them and for us. Communication needs to stay open.
  • Using IM rather then calls for technical discussion keeps a log that could be referred to later.
  • Because we kept on talking with the developers daily, a personal connection formed and they got more involved in the project
  • Their ideas were treated the same as ours and many of them have found their way into the endproduct. This motivated them even more
  • Using an agile development process also meant that we were all working on the same iteration and as such felt like we were in the same boat
  • We responded to their question in the same time frame we were expecting from them
  • A shared understanding that we will come up with more requirements as time goes by and a willingness on their side to change requirements and sometimes adding a requirement without charging for it
  • Our acceptance of real change requests without a lengthy price renegotiation. It started as a fixed price project and the price and time frame were adjusted according to the extensions
  • From early on using the developed software to track the project
  • And so far we still have not met a single person from that company.


    We are not advocating offshoring. What has worked here for us can also work locally but in our case we had no real choice because of lack of local expertise and limited resources. What has to be taken into account in our case is that we only partially offshored as we were part of the development team ourselves. We believe that in order to reap the real benefits of outsourced development, a company needs a mixed team, some developers are local and some offshore and that are able to interact as described above. In the future we will build a local team alongside the offshore team we used so far.