Selling Xp To Executives

One of the comments that KentBeck made at XpUniverseTwoThousandTwo was that the community hasn't done a good job of selling ExtremeProgramming to executives. Perhaps I misheard, because this seems to contradict a comment he makes in SellingXp, but nonetheless it's how I feel about it. I think ExtremeProgramming has very clear and compelling benefits for the developers, and for the customers, and good stories to get them across. While I think the benefits for the executives are equally compelling, I don't think we have a good sales message. -- AlexChapman

If you have to ask, don't do it! Executives are experts at being sold to by experts. If you're not an expert, they'll think it's what you're selling that's at fault. And if it's XP you're (not) selling, when it's such a gift to a salesman, you almost certainly haven't got what it takes.

It's a gift to sell because it's:

low, low up-front cost
low, low risk
novel
needed
ultra-quick payback
huge cost reduction
huge capacity increase

Why would an executive be interested in doing something just because it is novel? What I'm interested in is why it is needed, and how it provides ultra-quick payback, huge cost reduction and huge capacity increase. If these are so obvious and someone can tell me why, this really ought to be an easy sell. -- AlexChapman

Novelty sells. Executives are human. They buy novelty. As for "needed", most executives feel that they wait way too long to get way too little for way too much IT spend. They are desperate for a solution, have been for so long that it may temporarily have slipped their minds. Now the cost reduction and/or capacity increase depends on overall productivity increases within development. If you have a super lean, mean development machine, maybe the benefits won't be so great. But if that's the case, why try and fix what ain't broke?

The best thing about selling XP is that there's so little to lose. Pick some proposal with a puny business case that didn't get approval because it would take too long and cost too much and see how soon business benefit could start to accrue using XP. What resources would you need to get to that point (worst case, it's a total write off, but peanuts)? If you did nothing further, how long is the payback period? How does this shorten with a series of implementations? How much shorter is this than the failed proposal? Add the value of the shorter payback to the reduced overall development cost to show the benefit.

I have been thinking along these lines. Picking a project that didn't get off the drawing board, taking 4 developers and doing it XP, saying that in 4 weeks (2 iterations) we will have a working system to demonstrate, and in 12 weeks (6 iterations) we will have addressed most of the requirements. But I'm concerned that 2 iterations won't be enough to demonstrate the benefits of XP, and 4 developers for 6 iterations is close to a person-year of effort, which isn't peanuts. -- AlexChapman

If your executive isn't interested in any of these benefits, don't waste your time! And note the singular 'executive'. Just sell to the Champion. Let the Champion sell to everyone else. And don't sell, give. Let the Champion take the credit, get back to delivering value to your customers and watch the Champion fight your battle.

How do you sell (give) to your prospective Champion? Get the best natural salesman you have to do it. Or the Enthusiast; enthusiasm is infectious. If you're desperate, you could even stage a set-up where the Enthusiast is trying to persuade you to go further and you give voice to what you think the Champion's objections would be. A Champion worth having will side with the Enthusiast. You could lose your job this way, though, so be careful!

Technical Benefit: PairProgramming avoids silos of knowledge. You always have two sets of eyes on anything being worked on, and because pairs switch frequently knowledge spreads across all the developers quickly. UnitTests provide usable, up-to-date documentation. Developers learn new software best through examples, and a suite of JUnits is just that. -- AlexChapman

I've found the problem with SellingXpToExecutives is that we (meaning techies) tend to focus on the technical side of XP: PairProgramming, TestFirst, FortyHourWeek, etc. I believe this misleads executives and sets false expectations. XP (more generally, any iterative development model) is only partially about developing code. In fact, I'd argue that it's mostly not about developing code. XP is mostly about changing the requirements definition process in a fundamental way and that is what makes XP (and, again, iterative development) different from other development processes. By focusing on the technical side of XP, I have found that executives believe they will get X% improvement with changes isolated to programming productivity. Of course, if the requirements definition process doesn't also fundamentally change, at best they will see only a marginal improvement in programming productivity and, at worst, they will see a huge degradation of performance while programmer job satisfaction drops. -- MarkAddleman

I would agree, although in some cases executives can be quite technical and require convincing on both levels. So then the question becomes, how to sell the benefits of changing the requirements definition process? I think the message should focus on responding to change, and the business value of having the implementation track to an ever evolving understanding and definition of the requirements. What else? -- AlexChapman

CategoryExtremeProgramming