Xp Challenge Telecommuting

Formerly ExtremeProgrammingChallengeSix

You're consulting to a multinational with development groups from here to Kalamazoo. Three of these groups want to tap your expertise for a codevelopment that is very important to each. Trouble is, the three groups are in Timbuktu, Podunk, and Murcheson Sound. Logistics make it difficult for you to spend much time with all three in person, and impossible for each to work independently. Worst, the multinational wants to use this telecommuting technology they've heard so much about.

Could XP be successful here?

It seems to me that ExtremeProgramming works because it forces constant communication between the team members. The face-to-face communication substitutes for a lot of formal process that other groups use. Interactive communication is better for a team than emailing questions and answers back and forth. And finally, isn't ExtremeProgramming supposed to increase your productivity so that you don't need large teams of people? -- SusanJohnson

It is possible that nothing can be successful here. The question is what "work independently" means. Distributed development often fails. The trick is to reduce communication requirements as much as possible. Don't divide your project with "analysis and design in Timbuktu", "coding in Podunk" and "systems integration and testing in Murcheson Sound". Don't divide it as "database design in Timbuktu", "GUI design in Podunk", and "business logic in Murcheson Sound". If you can make it be something like "patient records in Timbuktu", "insurance management in Podunk", and "medical imaging system in Murcheson Sound" then perhaps there is a chance. Break the project into pieces and let one piece of the project be a customer of the other. This would let pair programming happen within each group, but not force you to do it between groups.

How good are the communication channels? An alternative might be to do pair programming across the Atlantic. If you had two-way high-speed video links and a fancy windowing system where you could see what was on someone else's screen then this might work. Time zone differences will make this be a problem. On the other hand, if each site has some people who prefer to work 5-2 and others who prefer to work 12-8 then you would already have this problem. You might require people to sign up for one of six time-periods (24 hours divided by 4 hours is 6) and require that all pair-programming be with someone in a different group. This would tend to spread expertise. So, if I am in the 8am-4pm EST group (which would suit me well, since I am in the midwest and prefer things early) then I would work with Europeans in the morning and Californians in the afternoon.

One problem with treating the whole project as a single development organization is that it would be hard to have a StandupMeeting.

-- RalphJohnson

There may be some technical support for PairProgramming: Imagine that I have two links, audio and digital, to my partner. The audio is a simple hands-off phone connection. The digital takes the form of one of these PC-Closeup type things, where I can drive your machine from mine. After all, the pairs work seems to focus on each of us having the same machine to work on. -- MichaelHill

I think this could work, would like to try it. -- RonJeffries

I share Ralph's concerns about this one. Was thinking that the thing to do was to change strategy from C++ to Smalltalk and let everyone go except in whichever location is closest to Ann Arbor. But seriously, folks, distributed projects are gonna be hard!

Speaking as someone presently involved in a distributed project, though in mostly a single timezone, I can say that, yes, distributed projects are hard. Video-conferencing is far from all it's cracked up to be, and shared windows/whiteboards are simply not as high bandwidth as a physical conference room. I believe distributed PairProgramming ought to be possible if the pair have some experience with it, but the real problem is keeping a common mental map of the development. Even meeting once a day, it's easy for distributed groups' assumptions, priorities, and connotations to diverge. PairProgramming will help this, but I'm interested in how things like ExtremePlanning might help too.

I don't believe, so long as you have the language skills, that distributed development is harder in C++ than in Smalltalk. Using a merging source repository like CyclicCvs, ClearCase or SourceSafeFive? enables ContinuousIntegration and then the other XP dynamics ought to be adaptable too. But C++ is the subject of ExtremeProgrammingChallengeSeven ...

I should also add an amen on the responsibility/geography splitup Ralph describes - by feature-set rather than by toolset or subsystem. Otherwise you're looking at compartmentalized expertise and very serious integration issues. -- PeterMerel

So is there any consensus about ExtremeProgramming (XP) working in an environment where team members are not CoLocated? Has anyone tried XP with NonCoLocated teams?

PairProgramming is definitely a plus. But can XP work without it? Should XP work without it?

Even better, can PairProgramming be done when the pair is geographically separated? With technology, remote PC control would solve the slide the keyboard dilemma. Could a telephone or PC based video conferencing solution solve the communication issues that the pair would face?

I would be real interested in any experience that anyone has had with this. I talked with LaurieWilliams (email actually) about this and she agrees that it should work but didn't know of any actual experiences. She did ask for volunteers for a study though ;-) -- AndyFutrell

I believe this will work too. So much so that I'm about to trial it in my organisation. We're planning to use something like NetMeeting to share desktops across locations and to allow developers "slide the keyboard" from one site to another. We're thinking about using audio conferencing across the net too. I reckon the NonCoLocated PairProgramming thing is gonna be easier to fix than having business in one location and developers on the other side of the country (UK) :-( -- TonyStansfield

With http://www.sealiesoftware.com/pssh/ or http://www.movsoftware.com/products/sshce/sshce.htm on your HandHeld and unix talk at the back end you could be VirtualPairProgramming from the bus stop in a howling gale or better yet sipping martinis from somewhere where it's sunny all the time.