How to use flexible tools / methods in a geographically distributed team

Question

I am working on a software project that several members work from home and some others work with timers. We meet physically once a month, at least. We communicate mainly by email. Our source code repository (mercurial) is located on the jungle disk (workgroup), which we share together.

We have a working product and one client. But we are not agile enough (i.e. One change in the code sometimes breaks something else, we do not have unit testing, the code is not documented, etc.). I want to use the Agile methodology to coordinate our work and track our progresses. I also want to use TDD.

The team does not have experience with flexible methodologies (or other methodologies).

What is the best approach to using the Agile methodology with a geographically distributed team? Which methodology is best for such a team? How to effectively implement it with minimal resistance?

Thanks!

Answer 1

I did this as part of the distributed XP source code and stories on three sites, each of which was 12 hours apart (Seattle, Bournemouth, UK and Singapore).

Here are a few reviews of what we have done:

• Distributed Flexible Templates: 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 bring everyone physically together at the beginning of the project to set standards and build relationships.

We also found that it helps to have “ambassadors” - to send different people between teams to spread knowledge and build trust.

We were fortunate that we had three sites, each time every 12 hours - so in the evening we could meet the meeting in the morning, and the last in the evening. We called them “handouts” and made them via video conferencing between the incoming team and the outgoing team.

We also found that remote pair programming works between a local pair and a remote pair (i.e. four people), but it is very intense and exhaustible and is best performed only for short periods of time. It is really important to see what other people do remotely.

Also: Kent Beck Tip for people using Eclipse for a remote pair: http://www.threeriversinstitute.org/blog/?p=584

Answer 2

Ok, my first thought, given what you pointed out:

Add unit tests to your source code!

Without unit testing, most Agile methodologies are not all that useful. Being Agile is being easy and being able to respond quickly to changes - unit testing is one of the main things that do this job. Without unit testing, you will never have the freedom to make changes without the risk of serious damage.

When you add tests, I will document your code. This, again, is critical to being able to make a difference, especially when the team is distributed.

After that, you can start implementing a different methodology over time. Personally, I would ask the whole team to do this and start working with daily / weekly stands (which work great with a distributed team through conference calls, etc.), where everyone describes what they tested, how they progress, etc.

This will at least lead you to the right path ...

Answer 3

Take a quick look at this blog post:

• You are not agile if your team is dispersed. Yes, right!

Answer 4

Start with continuous integration (auto build). I used CruiseControl.Net. I had two assemblies: 1) an automatic assembly after each registration, and 2) a test assembly for building on demand.

Answer 5

You need to improve your communication to get started. Yes, engineering practices are important, but communication is the key to flexibility. Email is not the most effective tool for coordinating a flexible project, but there is no shortage of tools that can help.

We had great success with Skype (mainly with a watch, but also with a regular phone), as well as with tools such as MS SharedView, and a demo version and even a joint program on different sites.

As soon as you begin to communicate effectively and feel like a team, the rest will follow. Agile is all about validation and adaptation, so try it all and enjoy it. Start by getting up daily and go from there. Regular retrospectives will help you identify problems and improve them.

Answer 6

If you use tools: to remotely perform pair programming or synchronous code checks, you can try the eclipse Saros plugin , which allows collaborative editing (including support for driver / observer roles and the following users through code).

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