Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

I've had experience as a developer or team lead on several projects that have been outsourced and have seen less than stellar results in all cases. Most of these projects have employed a waterfall philosophy, with large kickoff meetings, months-long requirements gathering phases, plenty of conference calls, and innumerable emails. One thing that's always frustrated me is an absence of early access to the code. The contracts are setup in a way where the offshore team is responsible for meeting functional requirements, which is what the executives are concerned with. This means, however, that architecture decisions, implementation details, pattern usage, and things that concern other developers are so deeply settled by the time the product is delivered that we're unable to offer feedback or request any real changes.

Has anybody here managed an offshore project that hasn't experienced these problems? Specifically, I'm wondering if there's any way to structure the contracts to compel offshore teams to work in shorter cycles and re-factor or re-design based on feedback from on-shore developers. I haven't had too much experience with agile methodologies (I agree with the general principles, but work in a conservative shop that has it's entrenched methodologies), but wonder whether these could somehow be adapted to help manage offshore development. Overall, I'm looking to minimize the surprises and maintenance nightmares that inevitably arise when a development team is left to work in isolation for months at a time.

share|improve this question

1 Answer 1

up vote 3 down vote accepted

I have done it and I prefer it. The contract will have to be on a time and materials basis, rather than a fixed bid. The fixed bid theoretically moves some risk to the vendor and may be more competitively priced but in reality it generates a need for so much more work like you describe, not to mention fights over change control definitions etc. So we just hire x number of bodies and work a lot more dynamically with them, assigning work on a task basis. They do not participate in Scrums though - there are onshore leads that will represent them. Essentially the onshore looks like he is doing the work of three people, but he is parceling out tasks to offshore. The onshore/offshore model does cost you some higher rates with the onshore person obviously.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.