Last night I attended the Agile Atlanta meeting last night where Jeff Sutherland, co-creator of Scrum, presented his experience with distributed teams and Scrum. He was a really impressive presenter.
The general idea of his presentation was that distributed teams should be working on integrated Scrum teams instead of isolated. He presented a number of cases where the teams had 'local' resources with the Product Owners and 'remote' resources elsewhere. For example one company built a scrum team of 4 engineers, with 2 in Denmark and 2 in India. Initially they all were together in Denmark for 2 sprints, then they broke them up. Jeff claimed that the velocity and quality of the team from the 2 sprints 'together' was continued when they were separated.
His reasoning was that because the team had started together, knew (and to some extent trusted) each other and were using the same tools they continued the same velocity when they changed location. He also said that the team had a shared sense of urgency about what they were trying to accomplish and the remote team knew the product owner and what he was trying to accomplish instead of him being a voice on the phone. He showed their velocity over a dozen or so sprints and pointed out a couple of anomalies, including one major one where the velocity took a nose dive. They found that it was the culture of the Indians, where the junior members (they now had 8 total members) were waiting on the senior engineer to tell them what to do. Once the team understood this, the team made the senior engineer the scrum master and told him to fix his velocity problem.
He also presented a number of cases where non-integrated distributed teams (both outsourcing and different offices) didn't provide anywhere near the same velocity as the co-mingled teams, as he admitted, contradicting all the Agile best practices of putting the teams in the same room. He presented that this was due to the silo building that went on with these teams since they had different priorities and sense of urgency.
He also had a great comment to someone asking about the lone expert who is the only one who knows how to do something: he advises his teams to not commit to anything where there is only one person who can perform the task. if they find a task that only one person knows how to do (he used the example of a deployment configuration manager at one of his clients), then the sprint should stop and the team immediately begin cross training.
The main presentation is here.
A posting about one of the teams he worked with is here.
A paper about the findings is here.
