Distributed 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.
