Test First, Test Driven Development and Distributed Agile

The more I deal with severely distributed teams (long way from Vancouver to Siberia!) the more I have come to view Test First and Test Driven Design/Development as a must for success. It is an uncontested fact that the lack of co-location is the largest downside to a distributed agile team, you can view the communication link within an agile team as a water system.

For a co-located team, the communication is a vast pool of knowledge that everyone can dip into whenever they please. As soon as you divide the team up, even if it is from one room to another, you need to put a pipe in place between these pools. The further apart you place the teams, the narrower the pipe becomes.

Now one needs to ask, how best can we fill this pipe? Are there any ways we can shore up the pipe with other means of communication. This is where I see Test First, TDD, executable requirements, Fit, whatever you want to call it but activities that help the team communicate the requirements and validate that the design and development underway meets those requirements without the constant need to fill up the pipe with clarifying questions.

Now pardon my belaboured use of the plumbing analogy (can't help it, I am an engineer!) but after an initial flood of communication clarifying tests and requirements at the beginning of the sprint/iteration/whatever (we need to start to have a unified language for these things ... a blog post for another time), these agreed upon, well understood, and continuously executed tests leave the pipe free to be used to communicate about creative problem solving and more truly profound questions about requirements, not questions like "should the discount be applied AT $50 dollars or AFTER $50".