Why agile and offshore aren’t compatible

Dear Bob …

In “Why offshore and waterfall go together” (Advice Line, 12/8/2008) you said agile development can’t work with time-and-space separation between developers and end-users.

I’d like you to spend more time discussing what about “face-to-face” is so essential to agile, that it can’t be dealt with using all the technologies we use for working remotely.

I’m not arguing — I’m just looking for your perspective. Thanks.

— Remotely Agile

Dear Remotely …

First, a clarification. I’m in the habit of using “agile” to refer to a broad family of iterative, high-end-user-interaction, incremental development methodologies. Recently it appears agile is, sadly, turning into the same sort of methodological religiosity that has afflicted many other methodologies (and no, I’m not going to troll by listing any).

In the future I’m going to refer to the broad family as “adaptive methodologies” instead of continuing to refer specifically to agile. So with that in mind …

I see three challenges with the technologies we use to work remotely: sensory limitations, interface distractions, and time zones.

Sensory limitations: With the possible exception of “telepresence” systems, which claim to replicate face-to-face dynamics (but which cost lots and lots), videoconferencing fails to convey most of the subtleties of face-to-face communication. The human eye has a remarkable zoom capability — you can look around a conference table and “zoom in” on each person’s facial expression without even thinking about it.

In a videoconference, when you show the whole conference table each face is just a few pixels. You have to manually zoom the camera to see one person’s face at a time.

This is just an example, of course — there are lots of other situations in which the sensory limitations of remote collaboration technologies come into play.

Interface distractions: Face to face, in a group meeting, anyone can walk up to the white-board and sketch or write, and everyone else just looks to see what happened. Using collaboration technology you need someone to run the interface, to switch people back and forth between looking at whoever is speaking, looking at other people in the room, and looking at the electronic whiteboard. Or, each person controls their own, which means they can give only partial attention to meeting content.

One-on-one, when you’re face to face, a developer can call over an end-user to look over his or her shoulder, point to the screen, and say, “What do you think of this?” You can accomplish similar results remotely, but it’s a lot harder. And that’s ignoring the seemingly trivial, but actually quite distracting delays that result from latency problems in a connection.

Time zones: This is the obvious one. When a developer is in India and the end-users are in Chicago, someone isn’t working during normal business hours. This is okay when it’s occasional. With agile, contact is anything but occasional. Beyond the simple human hardships this imposes there’s the loss of personal effectiveness that happens when someone has to either time-shift or work too-long shifts too often.

With all of this I’m assuming the team has had a chance to build face-to-face rapport before going remote. Without that it falls apart completely, because a key principle of process effectiveness (and a chapter in my just-released book Keep the Joint Running: A Manifesto for 21st Century Information Technology) is that relationships precede process — without trust among the process participants, nothing works very well.

That’s how it looks to me, at least. I’ll be interested to read the comments on this post to see how it compares to the opinions of more experienced practitioners.

— Bob