Since Yola (formerly known as SynthaSite) has a distributed team using many Agile practices, having Scott Ambler speaking in Cape Town on Agility At Scale was too good to pass up. Four of us from Yola woke up cruelly and unusually early to attend. It was interesting to me just how much of what I believe was described, although I did learn a lot too.
Distributed teams are hard, no matter the methodology followed. Scott reported (the numbers in the link are slightly different) that while 79% of co-located projects using Agile practices were considered "successful", only 55% of "far-located" (ie, requires a plane trip to get people together) teams reported that. I suspect that anyone who has had experience with both scenarios would not be surprised.
Distributed teams generally require "hand-offs", and these are generally done via documentation. Scott suggests that every hand-off contains a risk of defects being injected. He referenced Media Richness Theory, which posits that documents are the worst way to communicate information, whereas face-to-face communication (Scott suggests with a shared sketching area) is the best.
My experience with Open Source projects has shown that it is possible to have successful distributed development using text as the primary form of communication. However, I've found that those without experience with developing on Open Source projects generally just don't have the same ability to deal with text as a primary form of communication. (Interestingly, my best work relationships have almost always been with people who have developed on Open Source projects before.)
Scott's suggestions for organising distributed teams match exactly the suggestions I've put forward about distributed teams — basically that you should arrange the teams such that there is as little need for distributed communication as possible. Put another way — a team should be co- or near-located if at all possible, and able to perform as much of the work themselves without needing to communicate externally.
Answering a question from the audience, Scott promoted the idea of code, usability, and data guidelines/conventions so that team members could follow them themselves as much as possible to reduce reliance on skills silos in that area. He also suggested automating as much of the guidelines checking as possible.
On the subject of testing, Scott broke it up into two functions. Within the team there should be "confirmatory" testing — these are tests that the team make to confirm that they've developed a feature correctly, to confirm that they haven't broken an existing feature, or to confirm that a previously-discovered bug has not been reintroduced. The most common of these tests are unit tests, but other types of tests could be done here. Real professionals test their own stuff to the best of their ability.
He suggested having an external team of testers perform "investigative" testing — testing that determines suitability of the delivered software. This includes "exploratory" testing, which seeks to discover bugs through learning and use of the system as a user would, as well as usability and security testing.
On the subject of usability and security, Scott suggested that every developer be sent on a two-day usability course, and the same with security. Besides helping team autonomy, it also makes it easier for a developer to know when they're out of their depth in these fields so that they can consult others on how to address these concerns.
There were a lot of nodding heads and a lot of laughing from the audience. Some of the laughter was because of Scott's entertaining (if a little disorganised) delivery, but I suspect a non-trivial amount of the laughter was of the nervous variety as he nailed quite how dysfunctional and unprofessional our industry and organisations building software are.