I had an interesting discussion recently with two different people about moving toward a more agile development practice. The first was a potential client who had a small team in California. The second was a with the office staff of a services firm who wanted to better understand what agile is all about.
The interesting bit of the interesting discussion was the type of environment the groups wanted to deploy agile methods into: highly distributed development teams.
Uh, yeah, you could go agile... I guess.
So what does distributed agile really mean? Sure, I can do development incrementally and iteratively. Sure I can buffer the requirements so that all the real requirements work is done in a just-in-time fashion. Sure, I can let the team define and allocate the tasks necessary to meet the iteration/release goals.
But am I really being agile or am I a pig with lipstick?
I have concluded that one of the main driving forces that makes agile, agile is the constant in-your-face, here-are-the-facts, you-gotta-know-this feedback that permeates the agile team. Team member to team member, team to product owner, product owner to team. Agile is a do a little and get feedback, NOW!
Even with all the cool communication technology in the world, we really can't pull off that kind of feedback in a highly distributed environment. Heck, even the cool technology in StarTrek couldn't pull this off. The technology needed to make us truly agile is face-to-face people. Even then face-to-face is no guarantee. Face-to-face feedback can be limited, especially when I put the headphones on. Good face-to-face communication has to be cultivated.
Doing task cards over a web interface on three different continents is not really a substitute for the group standing (or sitting) around a table and a stack of cards. The job at hand does get done but little of Alistair Cockburn's osmotic communication is happening. Worse, feedback is delayed until the next scheduled meeting time. With limited up front work, agile relies on feedback at every stage of development.
My advice to those two groups was basically the same. Get the team together, for a least a while, to learn about each other. That will make the communication more personal and informative. Use things like instant messaging buddy lists and webcams to make the team feel the "presence" of all of the members. That will help them think like a team rather than associated individuals or, even worse, a local tribe. (A big problem with the "we code here and they test it at night there" approach. You can create software but are you agile?) Finally, try to partition the work so that at least some level of local collaboration and face-to-face can occur. Don't make every event have to span the location gap.
So is distributed agile really agile? It does meet the self-definition of agile that seems to be applied by the agile fanatics. It is a variation of the Forest Gump definition of stupid: "Mama always said that agile is as agile does."
Even when it may not be.