Does "scrum" work in offshoring?

I do a lot of work as an architect with offshore teams and some of these teams use Scrum development practices in their purest form.

I'm finding problems when developers are spread so far apart with pure scrum and wondered if anyone has solutions. 80% development is remote but some team members are US side.

The biggest issue is a lack of documentation - I'm no big believer in lots of docs but I like use cases or something that resembles a spec even if small. The remote developers just don't get a clear enough understanding of what is required even with all the meetings. New developers to the projects don't stand any chance of being productive.

Personally I'm pushing some teams back to just agile. Thanks!

From stackoverflow typemismatch

• In my (rather limited) experience, the only thing that works for off-shoring is Big Design Up-Front. And even then, you need a rather flexible definition of "works".

  From Shog9

• No. It's hard to be agile when the off shoring teams need cost estimates up front in order to sign contracts. Add to that, the near impossibility to have the team available to each other simultaneously (due to time zone differences) and projects with the outsourced company will fall back into a waterfall (from the your, the client's, perspective at least).

  The best way to mitigate this is to have the off shore company work on an isolated branch of code and have that delivered in as small of chunks as possible so that you can merge fairly regularly. Then your team can be agile and the off shore team can do whatever they want.

  If you all have to be working in tandem, then you will probably need a waterfall-like process.

  From Justin Bozonier

• Though the offshore team (or 3rd party) is likely not agile, you can remain agile yourself. You can think of their deliverable as your obstacle. Also, if the resource is flexible, you can send them a chunk of work to do, just like you front-load a sprint. It might freak them out though.

  From Greg Ogle

• It does, as long as at least one of them ( the technical leader usually ) in the remote location know what are they doing.

  It is not a matter of development methodolgy but of leadership and experience in the other side. It is ok to have a bunch of jr programmers in the other end ( that's what the offshore team usually do ) but is Key to have a very experienced developer ( or many depending on the team size ) to lead them through the sprints.

  Actually it is helpful because there are a lot of chances to get it wrong, and by the 4th of 5th iteration everything comes clearer.

  I think the same happend on local development team, but there you cans see who is not being productive and "substitute" him/her.

  :)

  Chris Hanson : Your formatting is messed up; you seem to be using " " to quote, which is Markdown for code-block. You should use "> " to quote.
  From OscarRyz

• With any offshore development (using any methodology) your biggest hit in productivity comes from time zone differences and impeded communication.

  The lack of synchronicity in working hours usually induces high latency in response times (one persons comes in for work while the other one is already finishing up, discovers a problem and then has to wait until the remote person gets back to work to have it resolved, etc.)

  High latency is especially problematic with agile methodologies as these methodologies rely on immediate, person to person communication. High latency also arises from less immediate forms of communication usually used with offshore development - emails, scheduled conference calls.

  To mitigate, I would recommend:

  A. Rely more on immediate forms of communications - IM, VOIP, person to person video teleconferencing. Consider having a webcam based teleconferencing system in each project room that is 'always on' and allows for more coherence between the two parts of the team.

  B. See if you can create more overlap in working hours by moving each part of the team's working hours 30 minutes to one hour closer to the other. This would buy you an hour to two hours of extra overlap in working hours.

  In general, however, I believe agile methodologies (capital-A Agile, SCRUM, XP) work better for offshoring than classic SDLC methodologies as the team's ability to respond quickly to changes that may result from cultural/technical misunderstanding is better.

  From Redbeard

• I've ran a few offshore projects and in my experience it does NOT. Mostly due to cultural issues w places like India.

  From Thomas Wagner

• Does scrum even work onshoring?

  Not in my experience.

  That said...The answer is no. If you don't have every t crossed and i dotted when you send a request offshore, you'll get back crap.

  They aren't trained to think agile, they are trained to follow a script and mass produce code.

  Dean J : If you pull the "Does scrum even work onshoring?", +1 on the post; Scrum works for my group onshore, but I can say I haven't seen it work with offshoring in the past.
  From FlySwat