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.

2 Answers 2


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.

  • It does not necessarily have to be T&M. I've seen agile projects with an outsourced team on a fixed price. The risk is then on the side of the contractor who has to be sure he'll be able to deliver.
    – mhr
    Oct 7, 2015 at 15:55

Agile development works best when it is fully implemented. Trying to combine just one or two agile concepts with waterfall development is a recipe for failure. Both clients and development teams must full embrace agile methodology. This means that both sides need to completely understand the advantages and restrictions of agile development as well as what is — and is not — possible, the commitments that each side must make and what changes each must make to achieve the maximum benefit. Typically, it is the outsourcer who must make the greatest number of adjustments, but clients must also have a good grasp of the agile methodology to avoid conflicts.

  • 1
    this post is rather hard to read (wall of text). Would you mind editing it into a better shape?
    – gnat
    Oct 7, 2015 at 15:25

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