doc, each contributor can add what he's doing as he does it. That way you avoid a spec of biblical proportions in favor of Agile documentation where every word is gospel.
Customer collaboration over contract negotiation
Okay, now this is an unsolvable problem. A global development team just can't collaborate with the customer the same way that an onsite team can.
Why not? I've already talked about how tools can close the gap between time zones. All we have to do is apply the same philosophy to the customer.
To me, this kind of transparency is the customer's right. In our projects, the client is a major player. Every client gets access to everything every team member does: the client can read the developer mailing list, phone the team lead at any time, and post stuff to the wiki. The customer should have the right to contact any developer by email, Skype, or IM.
Even if the client is less technical and doesn't find bugs in the code or have suggestions for test strategies, he does have the right to ask for a working build any time. And giving it to him lets him evaluate our progress and request changes. Luckily, giving the customer a working build whenever he asks isn't a problem(See previous bullet point) because our peer review process catches bugs before they make it into the build. So we can be sure that the build from any random day isn't going to nuke the client's computer on install.
Responding to change over following a plan
There's no way a global team can respond to change like a team that isn't spread all over the globe. Due to the different time zones and communication issues, they just can't have the same quick turnaround.
Besides, global developers like plans. They're used to working that way. They're also better at following a plan than turning on a dime.
Instead of changing the plan, plan to change.
Short iterations. Lots of small milestones. Contributing to the project in a democratic, wiki style. Soliciting customer feedback. All these things will help a global team respond to change quickly.
And the time zone problem isn't as bad as advertised. Let's say that you're in Silicon Valley and discover an issue at 3:00 PM on Thursday. But you can't tell your developers in Nagpur to fix it because they're asleep. So, until close of business, that issue won't be fixed.
However, if you send the email right away, chances are they will have made good progress on the solution by the time you have your Friday morning coffee-after all, by your 9:00 AM, it's their 9:30 PM and they will have had all day to work on it.
But I won't lie to you; there's some truth to the idea that global developers are less familiar with the Agile style and are more used to working on well-spec'ed out projects. This is where you have to go back to the beginning of this article and read bullet point #1 again. It's all about you building a team culture that means responding to change is the rule, not the exception.
My last point doesn't have much to do with the Agile manifesto, but I want to make it anyway. Building an Agile team culture with a global development team isn't easy, and it may take time for team members to get comfortable with it. You can't just say to a person who is used to working on well-defined products, "Hey, you get to be Agile now!" and have them shouting yippee.