Managing an agile software team in 4 countries

We’re now two months into CALIBRATE, a huge software development project funded by the European Schoolnet. It has close to 20 partners in different EU countries, and our team is coordinating one of the work packages, where we have 30 months to build a jazzy web portal for creating, browsing and using learning material in the EU. We’re calling it the “Toolbox” for now.
From the software development point of view, the most interesting aspect of this project is that we’re attempting to do agile development (using a modification of Scrum and XP) with a team of 8 developers, which reside in four countries (Estonia, Finland, Hungary, and Norway). And one of the most important principles in agile is to keep the team together. Well, also in a waterfall splitting the team apart is always an issue that needs addressing.
So the problem is that there’s a few people in each country. No location has enough people to form a working development team. So somehow we need to create a team that is present in all four locations simultaneously. Having attended Agile Finland’s seminar in Helsinki I was convinced that one of the key make-or-break issues in this project will be communication and team dynamics.
A good book to read was Organizational Patterns of Agile Software Development by James O. Coplien and Neil B. Harrison, which is basically a collection of best practices (or patterns) for software development, from the point of view of the people doing the work.
A plan was then set: Geographically distributed work can work, as long as no-one is left out of the loop. This means that no important decisions should be done by people in one location alone, and no information should be held in a place where others cannot access it. So everything should be done as openly as possible. After a quick review of available software, we decided to go with Trac, which is an open-source development platform that integrates a wiki, a ticket system and version control into one browsable, interlinked web interface. You can take a look at our project’s Trac site at http://goedel.uiah.fi/projects/calibrate/. The burndown chart and time tracking are additions to the plain Trac, which allow some measure of time estimation (the burndown chart is a Scrum practice).
When browsing our Trac, you’ll notice that everything is done completely visibly. All meeting minutes are there, all discussions about concepts and features are there. Every patch commited into the version control system (subversion, btw) is connected to a defect or enhancement ticket, which in turn is connected to a user story ticket. So the reason for everything that we do can be tracked down. Our team also has a mailing list, where Trac automatically sends all ticket changes, and Subversion sends all commit diffs.
And yes, we did start with a “Face to Face Before Working Remotely” by inviting everybody to Helsinki for a week for an intensive workshop, sauna, and swimming in the sea (in November). I’ll post another entry discussing the organizational patterns that we use more closely.