Problems With On Site Customer

[Moved from WhyItIsSoHardToSellExtremeProgramming]

At my last contract, the other guy on the project and I introduced a couple of practices at a time (eventually getting up to about half). Some were easy to sell: for PairProgramming, I just dragged my partner over to my cube and started programming with him. Once we were started, it was hard to stop.

Some were harder to sell, such as the PlanningGame. Our manager was our OnSiteCustomer. He really did know more about what the program should do than anyone else in the building. When we went to him with a bunch of estimated StoryCards that we'd created from his list of features, his first reaction was, "This is too hard." But we kind of dragged him through it: we made him sort them into "Now", "Later", and "Maybe Never" piles, then asked him about rearranging one or two stories so the "Now" pile would fit in our first two-week iteration. It took about forty-five minutes, and while we didn't ask him if he still thought it was hard, I think we'd changed his mind.

Maybe this is a general pattern for selling ExtremeProgramming: TasteTheSoup.

-- GeorgePaci

"Our manager was our OnSiteCustomer" Doesn't sound like XP to me.

Well, doing only half the practices hardly counts as XP either. So keep a caveat in mind for what follows: This may not apply to you, your project, or any XP project; your life may be vastly improved by never reading it at all. But I think it's probably broadly applicable, and it raises some interesting issues, so:

The guy we had as our OnSiteCustomer was a mechanical engineer by training who knew a lot about the problem domain and how actual engineers got actual work done in it. When I say he was our "manager", I mean he was the one who got us our budget, fought the rest of the organization to keep us from getting cannibalized, asked us to fill out various legume-enumeration reporting devices, etc.

The company had no sales or marketing organization, which is usually where you'd find an internal OnSiteCustomer. Additionally, the product was being developed for a sister company, rather than some big external market (though, in my opinion, management never realized how broadly applicable the product is).

So was he the ideal OnSiteCustomer? No: he didn't have to use the software to get his job done. Was he better than some random MBA? Definitely: he'd done the things the software was supposed to help with, and had a theoretical knowledge of the area to go with that practical knowledge. Did the fact that he was formally our "superior" hamper him in his role as Customer? No: we had a very free hand in how we got things done. As I said, we even got him to do some XP things.

Would one of the actual users of the software have been a better OnSiteCustomer? Yes, but there really was no chance in hell we could get one of them to our location for the project; we couldn't even get down to their location to orient them to the software. (You'd think the fact that the users were in a sister company would make this easier, wouldn't you?)

The lesson I learned (but see caveat, above): One of the ways a big, rigid organization hampers ExtremeProgramming is by making it hard to get a good OnSiteCustomer.

-- GeorgePaci

I would say that the OnSiteCustomer is the biggest shortcoming of XP. It simply is not practical for the vast majority of projects and a better requirements gathering and evaluation is needed. [I raise this as a problem in its implementation; the presentation of XP to "non-believers" has a lot of other problems.] -- WayneMack

"It simply is not practical." I think this is one of those places where something new and different looks impractical, even if it isn't. CodeUnitTestFirst didn't look very practical to me at first, nor did TestEverythingThatCouldPossiblyBreak, or even ConstantRefactoring?. If you want to do XP, you have to re-examine ideas about what's practical and what's possible.

In my case, I think it would have been pretty easy for a multi-billion-dollar company to take a mechanical engineer and put him up in a different state for a couple of months. If that would blow the project budget (hard, given that it was in the hundreds of thousands of dollars, but still possible), here are some alternatives:

Tell one of the (off-site) users that his top priorities are answering the developers' questions over the phone and specifying AcceptanceTests; fly him up for PlanningGame sessions. Ditto, but fly the developers to the customer location for PlanningGame sessions. Assign the project to a development group that's closer to the customer (with being in the same room the ideal).

These are all clearly within the abilities of the company in question. So it's not a question of "practical, given our resources", but rather, "practical, given our politics and managerial will and commitment to ExtremeProgramming".

-- GeorgePaci