DiggDistributed agile teams can work, but it is risky. Even more than traditional agile implementations, distributed teams tend to fall into two failure modes: “command as control” or team fragmentation.
Why?
Agile methodologies warn how critical it is to co-locate teams in the same room, but this is not always practical. 
Distributed or “virtual” teams are a reality of business today. Offshoring, flex-work schedules, multiple corporate offices, and other forces create pressures to achieve results even when team members are scattered across the globe.
But most of these distributed teams seem to prove the Agile warnings right by demonstrating old habits of waterfall behavior. Long cycle times and endless requirements revision are the norm, status reporting takes up far too much time, and individual leaders dominate the team. Management direction gets lost in a sea of process and tools instead of manifesting as tangible, quality product.
How can we realize the benefits of Agile product development – hyperproductivity, high-quality products, self-organization, elimination of waste, and rapid releases – when team members are not sitting next to each other? How do we make scrum distributed teams work?
This is the challenge of business in the 21st century: how to work effectively at a distance.
I am finding the discussion regarding distributed teams to be similar to the task-switching discussion. With the amount of research time spent identifying and quantifying the costs of task-switching in terms of mental effort and time expended, it seems that similar research and analyses could be done regarding distributed teams. For anyone that has been on conference calls and attempted to collaborate with remote team members, they would talk about the amount of extra energy and time expended on communication, documentation, running meetings, etc., none of which has a direct impact on the product at the end of the day. Also, these costs are not accounted for in any estimates, nor is the opportunity costs weighed in terms of energy and time that could be spent on other tasks, just as in the case of task-switching. We need to understand what problems we are solving with distributed teams to determine if we can solve them another way, otherwise we may get crushed by the law of diminishing returns.