Selling Xp

Given that NameXp is a moot point by now, more of the discussion is around selling it. Discussion moved here accordingly.

I too originally thought that the name ExtremeProgramming might not seem like a good idea, but having just spent numerous hours explaining this thing we call XP to numerous suits I can say with conviction the name is correct. It is a very fresh approach and as such it deserves a name that attracts attention and makes it stand out from the rest of the methodologies.

When I am explaining the methodology I always start out by asking if the interviewer has heard of KentBeck and his work. I have only gotten a yes once. I then talk about streamlining the software process saying things like: "most methodologies want you to test, but we really do test, in fact we write the tests first." "Most methodologies want you to review your code, we continuously review our code by working in pairs." Etc.

I go on through the various things that currently accepted methods espouse but never fulfill and I say why XP actually delivers. I finish with "...and that is why I can say it is 6 times faster." Now at this point I will either be asked for a name or I just tell what the methodology's name is. The interviewer will invariably pause to write it down. --DonWells

but when they go to repeat what you told them they'll likely say, "I heard about this really kooky but kind of cool thing the other day, ExtremeProgramming ...", and then they're dealing with a bad reaction before they've said word one about what XP actually means.

Part of the problem is exactly the problem we had at MasPar- we have a solution and most folks don't even know there is a problem. Our marketing guy used to say, "First we have to create the mailbox in folks' heads, then we can start delivering messages to it." Managers and customers have no idea that they can and should demand the kind of accountability and flexibility that XP can produce. Decades of interaction with IT have them conditioned to expect long dark periods followed by disappointment.

Some people know about EvolutionaryDelivery. One way of looking at XP is that it is a technical strategy that can execute EvolutionaryDelivery indefinitely with programmers of ordinary skill. Folks who want ED but are afraid may be able to see how XP addresses those fears. But again, the audience for ED is currently small.

I don't have an answer. When I explain the technical strategy to technical folks, they either love it or hate it. When I explain the management strategy to upper management, they love it. But our big problem is getting customers and managers to demand transparency, accountability, and flexibility. Once they know to ask, we can deliver. --KentBeck

[The above example sparked the FirstCreateTheMailbox pattern]

This is interesting, CanXpChange

I don't know where it comes from with others, but I've had the following conversation with both my managers (don't ask), all my developers, and 3, count 'em, 3, corporate auditors:

Newbie: So what effort is this project making to meet the SEI CMM / corporate methodology standard / MicrosoftSolutionsFramework / RationalUnifiedProcess? We're very big on that here you know.

CapedConsultant: Our process meets that standard 100% <flashes ExtremeUnifiedProcess documents - though not by that name> In the case of the CMM, we're actually surpassing corporate expectations - we measure and optimize our process as we go.

Newbie: ... but we can't possibly afford to do all this. We have a deadline!

CapedConsultant: <thinks: A deadline! Run away!> Our process has been demonstrated to dramatically increase both delivery speed and quality.

Newbie: Oh it has? When and where did it do that? This isn't something you cooked up yourself?

CapedConsultant: No, this is the spiral/iterative/evolutionary methodology that's beaten all comers on the PortlandPatternRepository <gasses on about Beck, Cunningham, some bloke named Ron, CRC, C3, patterns, cowboys, big design ... oh please don't make me say the name ...>

Newbie: Fascinating. Sounds like it has great potential thoughout our organization. What's it called?

CapedConsultant: <damn! Think fast!> Evolutionary Programming. Or some call it <mumble> Programming.

Newbie: <writes: Evolutionary Programming.> Where would I find more detail on it?

CapedConsultant: There are complete references attached to these docs. <don't ask about the book, please!>

Newbie: Hmm. Evolutionary Programmming ... I like the sound of that. Is there a book?

CapedConsultant: <how fast does a corporate crimefighter got to talk just to do some work around here?> There's a new one just about to be published. I'll send you a URL when it's out. But as I said we're also drawing heavily on RUP and MSF, so you might start with those ...

So far, by the time your new chum has worked through the ExtremeUnifiedProcess chunk, and figured out what we have to do with RUP and MSF, and looked around at stuff on EvoFusion, EvolutionaryDelivery and maybe stumbled over something on ExtremeProgramming, they figure either (a) "By god this might actually work!" or (b) "We'll never cut through this much hogwash in time to save the project!" At least so far no one's come around and tried to slap our wrists. But we have to deliver, and deliver good, or this poor old CapedConsultant is going to be spending a lot more time lounging around his mansion with the GirlWonder?. And the GirlWonder? wants to renovate ...

I like the comments in CrossingTheXpChasm, suggesting that you need a different approach to sell to different segments of the market. To sell this to middle and upper management, one needs a "sales approach" (ick!) with images and names that immediately suggest the most relevant attributes of the product your selling. When you tell them you want to do "N," the name "N" has to be something they know they don't fully understand, but which they feel they'd like to know more about.

The notion of bringing XP in one chunk at a time makes a lot of sense. Most projects are underway: few are beginning. Full methodologies are, by and large, declared into use by fiat, and observed little or not at all. In my three years at Chrysler, I have used the term "Extreme Programming" essentially never in discussion with management. --RonJeffries

I have been known to refer to it as "Kent Beck's work" until I have the audience rivoted in suspense. --DonWells

When selling ExtremeProgramming to suits I like to start with the fact that this process is one proven, successful way to reengineer the software development process (see XpIsResultOfApplyingBusinessProcessReengToSwEngProcess). By using something suits are familiar with (BusinessProcessReengineering) as well as has been proven successful in many areas of business it seems to get ExtremeProgramming accepted more quickly accepted. BusinessProcessReengineering is pretty extreme (HammerAndChampy? say that radical is the most important word in the description of BPR) so the name fits without too much excitement. --HankRoark

WhyStickWithXp? WhatsExtremeAboutIt?

I think that what REALLY works is to start small and limit your initial investment. Don't get focused on selling the approach across the collective. Just find a way to get starting adapting the practices and philosophies in your own vicinity.

What we did on the DoIt team was just -- start using XP practices. Without any selling. Without anyone outside the team especially knowing. We figured out how to "plug" our practices into whatever surface artifacts we needed to support.

Now that we have a two year history of successful delivery in the face of rapid change, we're getting some attention. Enlightened teams have been able to smell the difference for a long time -- now other managers want to know how we do what we do. And, may the timing gods be praised, now we're starting to see lots of web presence (and Kent's new book) to help us sell the concepts. But our credibility is based on consistent delivery, not on the philosophical value of the approach.

And that is actually a big difference between XP and the methodologies I've heard preached in the past. You CAN deliver head-turning results, and create an environment that the very sharpest people in the organization are eager to join. In the end, you don't have to base the sales pitch on the theory. Put it in practice in a small way, and you will create real-world arguments for the value of the approach. You DON'T have to invest thousands of dollars per seat in massive modelling and repository tools.

The name is less important than the results. -- BillBarnett

Interested in drilling down specifically on messages for SellingXpToExecutives. Agree with introducing XP in small pieces by stealth (and have been applying that) but there comes a point where you want to try a project using all the practices, and this seems to be when you need to be able to persuade senior management --AlexChapman