Xp Versus Agile

Maybe the community needs to invite EricRaymond to provide a soft, fuzzy, management-friendly name other than "Agile". That way die-hards can continue to insist on the proper term of ExtremeProgramming, and wishy-washy moderates can switch to the equivalent of OpenSource.

"customer-driven"? "results-oriented"? "lean-n-mean"? --Not Eric Raymond

"reality-embracing"? -- Also not ESR

If there needs to be another name for XP and/or other 'agile' processes, I suggest getting away from the one-word-symbolic-name thing. Management types like flaky acronyms, especially ThreeLetterAcronyms?. E.g. CMM, RUP, UML, and heck, even XML. XP doesn't work because inevitably, they're gonna want to know what the 'X' stands for, and 'Extreme Programming' isn't flaky enough. (And also, it's only two letters...)

Well, that's easy. The last letter invariable stands for some meaningless category word. So, LWM--Light Weight Methodology.

Good try, but it doesn't roll off the tongue. 'W' sucks for that. Sometimes I wonder how the WWW became so popular, but I guess it's because it's three Ws in a row.

A lot of people pronounce it wah-wah-wah, or some variant thereof... In German-speaking countries (including Switzerland, home of CERN, as I recall) this would be pronounced "vay-vay-vay", so maybe it's not so strange? I'm in the US, I almost exclusively hear either "double-u, double-u, double-u", or among the tech savvy, "dub, dub, dub".

I always thought Responsive Methodology was a good alternative to Agile Methodology, since its not just about moving quickly, but rather moving quickly in response to things happening around you In terms of XP, I sell it to my boss as "Business-Value-Driven Development" -- AnthonyLauder

How got this page its name? I reads more like BetterNamesForXpAndAgile?.

Is all this about semantics? Is the naming convention that important? Heck, I sure can't sell the XP idea too easily, so what matters the name?

: I find, sometimes, selling XP is difficult because it addresses engineering practices and the people who need to be sold are not technical people. That's where developing a more abstract or generic vocabulary about Agile becomes important. We must speak in terms people can really hear, and sometimes that is the language of business: ROI, Risk, etc. The people making the budgets for entire IT departments don't care about PairProgramming, just about "faster delivery of critical functionality" - who cares how you do it? --DeborahHartmann