we were discussing how simply being “in the same room” is not enough to make for a successful project. I contended that a distributed team can force the issue of doing best practices in terms of collaboration and being very visible.

when i worked with a team in St. Petersburg, RU, I would be onsite 2 weeks per month. i would have been more effective being onsite 100% of the time. (We were developing software products at TogetherSoft.) However, being a distributed team meant i had to increase the level to which we ensured we always worked by being open, communicative, and extra visible. so, we were more certain to have collaborative tools…

• tools to control the features — not a bunch of cards physically limited to sitting in some room.
• models and design ideas on wikis — not just on a whiteboard
• design by interface to avoid dependencies whose impact can be exaggerated in distributed team dev
• web meetings to discuss items with the team (usually said documentation and design ideas)
• plans and progress visible in wiki

the benefit? this not only served the local purposes of the team, but it was useful for anybody else who might be interested, or who wished to collaborate — without having to be in the same room (or continent). Also very useful for newcomers to join the project mid-stream.

some teams would be content with doing just enough to meet their local needs. which is fine. (an extreme example might be a solo developer that does not docs or design or project wiki.) my point was that if you want to succeed and you are doing distributed team dev, you better adopt some best practices that help keep everyone on the same page. this can lead to a distributed team having to go further than a local team would in terms of building a collaborative workspace and artifacts. Obviously, nothing precludes a local team from doing the same activities, it is just that a local team need not to it to succeed; whereas, a distributed team lives and dies by proper collaborative techniques and tools.

so, while a local team can do the same level of collaboration as a distributed team, they do not have to, and often do not. the converse is not true. a distributed team will quickly fail if good practices are not followed.

maybe a corollary to my point… if you cannot do development well locally, you likely will not get any better results when you add in 12 time zones.

we have been doing agile development with teams across 4 continents now… with success. sure, sometimes i wish we were together, but skype and other techniques can help bridge the gap.