How to use agile tools/methods within a geographically distributed team

Question

I'm working on a software project which several members are working from home and some other are part-timers. We meet physically one time each month at least. We communicate mostly by emails. Our source code repository (mercurial) is on a jungle disk (workgroup) that we share together.

We have a working product and one customer. But, we are not agile enough (ie: one change in the code sometimes break something else, we don't have unit testing, code is not documented, etc.) I want to use an Agile methodology to coordinate our work and track our progresses. I also want to use TDD.

The team has no experience with agile methodologies (or other methodologies).

What is the best approach to use an Agile methodology with a geographically distributed team? Which methodology is best with that kind of team? How to implement it efficiently with the least resistance possible?

Thanks!

Answer 1

Have a quick browse through this blog:

• You're not agile if your team is dispersed. Yeah right!

Answer 2

Well, my first thought, given what you specified:

Add unit tests to your source code!

Without unit testing, most Agile methodology isn't all that useful. Being Agile is about being light and being able to respond to change quickly - unit testing is one of the main things that makes that work. Without unit testing, you'll never have the freedom to make changes without risking major breakage.

As you add tests, I would document your code. This, again, is critical for being able to change things, even more so when the team is distributed.

Once that's done, you can start implementing other methodology over time. Personally, I would have the entire team do this, and get started on having daily/weekly stand-ups (which work fine with a distributed team via conference calls, etc), where everyone describes what they've tested, how they're progressing, etc.

That will at least get you on the proper track...

Answer 3

Start with a Continuous Integration (automated build). I used CruiseControl.Net. I had two builds set up: 1) an automated build after every check-in and 2) a test build to build on demand.

Answer 4

You have to improve your communication for a start. Yes, engineering practices are important, but the key to agile is communication. Email is not the most effective tool to coordinate an agile project, but there are not shortage of tools out there that can help.

We have had great success with Skype (mostly pm, but also normal phone), and also with tools like MS SharedView it is possible to demo and even pair programme across sites.

Once you start to communicate effectively and feel like a team, the rest will follow. Agile is all about inspecting and adapting, so try things out and have fun with it. Start with the daily stand up and move on from there. Regular retrospectives will help you identify you problems and improve.

Answer 5

I have done this as part of a distributed XP team sharing source code and stories across 3 sites, each site being 12 hours apart (Seattle, Bournemouth UK, and Singapore).

Here are some write-ups of what we did:

• Distributed Agile Patterns: http://www.keithbraithwaite.demon.co.uk/professional/papers/index.html#europlop2005
• http://www.keithbraithwaite.demon.co.uk/professional/papers/index.html#xp2005

We found that it helps to get everybody physically together at the start of the project to establish standards and to build relationships.

We also found that it helps to have "ambassadors" - shipping different people around between teams to spread knowledge and build trust.

We were lucky to have three sites that were each 12 hours apart - so we could have a stand-up meeting first-thing in the morning and last thing in the evening. We called them "hand-over meetings" and did them over video-conference between the incoming team and the outgoing team.

We also found remote pair-programming worked - between a local pair and a remote pair (i.e. four people) but that it's very intense and draining and best done only for short periods of time when it's really critical to see what other people are doing remotely.

Answer 6

If you are into tools: To be able to do pair-programming or synchronous code reviews remotely, you could try the eclipse plugin Saros, which enables collaborative editing (including support for driver/observer roles and following users through the code).

(Disclaimer: Saros is a project of my working group at Freie Universität Berlin)