When Xp Is Unpopular

I like ExtremeProgramming, not least for the fact that it seems to be able to PlugPeopleIn?. -- PeteMcBreen

Just to balance things out, and to see the other side of the EmotionalReaction?, let us explore WhyXpIsPopular, and later on we can try to hunt for the GoldilocksSolution. -- PeteMcBreen

If humans were supposed to fly they'd be born with stewardesses...

Candidate Reasons

1. XP challenges our basic assumptions about the software development process. This is a strong candidate, since the results XP is reporting are kind of CounterIntuitive.

2. XP challenges deeply entrenched, learned resistance to whatever latest Morgatrond Thumpwistle Heavy Methodology our computer-illiterate managers have been screaming at us to use for decades. When we learn to despise and fight any methodology, sight unseen, we tend to attack introductions to XP as "Just Another Paperwork Silo."

3. DoTheSimplestThingThatCouldPossiblyWork seems too simple for this stuff to be real, they must be ReallyDoingSomethingElse?. Given the reactions to the simplest thing, this is another candidate. Is it just my imagination, or do colleges teach Do The Most Complex Thing Possible (combined with NotInventedHere)? This could be a clue.

4. Some of the people writing about it are kind of, um, well, uh, pushy? --RonJeffries

5. XP challenges the heart of the SEI/CMM world. The CapabilityMaturityModel is only one possible description of the software development process and how to improve it. XP seems to be suggesting that actually trusting your developers to follow a process is an alternative path to a highly productive, optimizing software development process.

6. This PairProgramming stuff is kind of kooky. Works, though.

7. You mean I have to like actually TestMyOwnCode?

8. We staffed a whole QA department. They have to be given something useful to do. So tell the developers to stop testing, the QA department will do it for them, and save time. (Don't laugh, I've actually seen this done!!!)

9. Everyone knows that TestsCantProveTheAbsenceOfBugs. Therefore extensive testing does not work, what you should be doing is FormalDesignReviews? of UmlDiagrams before you write a line of code. Anybody who would even suggest otherwise must be .... this rant and rave can go on forever

10. Why didn't I think of it?

11. People do not understand what DoTheSimplestThingThatCouldPossiblyWork means - I know I didn't at first. It needs to be contrasted with what Ron calls "Experiments", which are ugly yet simple ways of seeing if something will work, and which are quickly displaced by the simplest possible thing that could work: i.e. a better factored, easy-to-read and maintain version of the thing. --JoshuaKerievsky

12. The name "ExtremeProgramming". I must confess I had seen several of the ideas of ExtremeProgramming before (I know, "everyone" says this...). Actually we went through a BrainWash? by TomGilb with his Evo/PLANGUAGE stuff [see http://en.wikipedia.org/wiki/Planguage]. Imagine being a consultant (MakeMoneyFast :-)) and you approach a manager with the statement "From tomorrow on you should do Extreme Programming.". Sounds a little bit radical compared to "From tomorrow on you should do evolutionary development.". -- ThomasWeidenfeller.... From AtsGoesExtreme: ... a methodology whose name sounds like it was born from a surfer's hangover. ("Whoa... dude... you're a programmer? That's, like, extreme, man! Yeah, you're an extreme programmer, dude. Heh heh.") Likewise, see DontCallItExtreme

13. The marketing of the method. This is somewhat related to the previous point. I recently attended a presentation about XP at a conference by KentBeck (App. Dev. '99 in London). This is not to criticize Kent, but he spoke on the level of one programmer to other programmers. Methods are, however, not least management decisions. They have to be convinced first, because they make the decisions about methods, they spend the money, they have to believe. Speaking about code to managers is not a good idea.

15. 3x5 cards are cheap. There's no profit in marketing design and analysis methodologies whose tools are just 3x5 cards.

16. Doing the simplest thing that could possibly work usually doesn't include writing a popular book about your methodology. So there are many many more books about much more complicated methodologies. I hope KentBeck proves you very, very wrong. -- PaulChisholm I hope he does too! -- PeterMerel

17. Management doesn't think iteratively. So it's hard to get them to accept any iterative methodology. Not likely!. When I was a manager, I would have killed for a process that let my developers say to me, every few days or so, "That feature is designed, coded, tested, doesn't break the world, and is under source control." Killed, I tell you. --PaulChisholm You'll forgive me, Paul, but you don't sound like the kind of management I mean - the kind to whom schedule negotiation is a one-way street. -- PeterMerel

18. This stuff comes out of the smalltalk world. Who the hell works in smalltalk these days? Okay, a few crackpots, but come on, get serious ...

19. They started late.

20. Doing this requires a lot of rigor and mental change in the developers. Them that are used to hacking have to get used to testing. Them that are used to designing have to get used to CRC. Them that are used to lonely work have to get used to partnering.

21. There really isn't an XP community yet. Those of us who are enthusiastic about the idea will no doubt form one, but for now you can count the ExtremeProgrammingProjects in the world on the fingers of one hand.

22. There's no XP consultants or training courses. Well, maybe you can go sit in with Ron and Kent, or ask them to kindly come sit in with you, but you can't get your local body shop to supply folk with these skills.

23. There's no role for pure Analysts, Business Analysts, pure Methodology Experts etc.

24. We trust the programmers to manage themselves? So we need less management. What about my job security? What about my IllusionOfControl

25. You need a BigDesignUpFront, otherwise you won't know what impacts what, and the development will fall apart.

What's the alternative? Structured analysis and design. "Classic" responsibility-driven object oriented analysis and design. Rum-booch-tory with UML. Cleanroom development. Shlaer-Mellor. Fusion. Strict CMM (which is really orthogonal to these methods, since it talks about measurement not artifacts). "Code-you're-done." None of these is perfect. All have been behind many successful projects. Peter, if you've moved beyond these to Xp, and you're happy where you are, I'm happy for you. Questions such as "What's the alternative?" do help answer the question, "Why is Xp unpopular with some people on Wiki?" ... but maybe not the way you thought. -- PaulChisholm

Um, you read a lot into a little phrase. I've tried a fair amount of what you refer to, with varying degrees of satisfaction. As to moving to Xp, while I'm very sympathetic to it I'm trying to find the right context to apply it. I don't expect it to be the one true faith - see comments on WuWei for reasons why not. Moreover I'm very well aware that there are many contexts where XP would be a bad choice of methodology. But I write "what's the alternative?" because I personally don't know something that I personally would rather use. Perhaps this is only my antipodean inflections coming through - I've been bitten by my upbringing before - but I meant nothing more than that. I certainly agree that ExtremeProgrammingIsNotTheOneTrueFaith. -- PeterMerel

Here's another one.. I wouldn't say it is operating now, but it will:

0. "Are you telling me that everything I've learned over the years is less important than how well I communicate and coordinate with my coworkers?"

It is a very humbling proposition. People say that two heads are better than one, but when the truth of that really sinks in there are a lot of bruised egos to contend with. Sad to say, but there are many people whose sense of self-worth is incredibly dependent upon how they rate their skills against their peers.. more competitiveness than cooperation... they'll code like hell until they are the monster-gods.. so smart that they never have to write code.. they can drop UML diagrams on the masses; and that is only within teams. Industry-wide, there are many people who make a fine living by telling people that things are harder than they really are. I shouldn't knock them, because many of them are sincere, but nonetheless they have much to lose if the work is seen as simpler.

-- MichaelFeathers

My reaction to XP is this: many of the core ideas are solid.

Much like patterns, many of them don't seem to be particularly new to me. I've been constantly refactoring and striving for simplicity for years now. I showed the XP pages to a coworker, a guy with a C++ background who now does Java. He was familiar with them too.

Some of the ideas are new to me, and seem like pretty good ones. I like the idea of UnitTests a lot. I have some doubts about the level of granularity-- unit testing each object just feels a little too fine-grained to me. On the other hand, I think this is, to some extent, a matter of comfort with refactoring. The more unit tests you have, the more confident you can be that you haven't screwed things up. Hence, fine-grained unit testing lets you confident when restructuring code and enables larger, faster, single-step changes than would otherwise be the case.

But some of the XP rhetoric just seems wrong. I think there is such a thing as design. To give some context: I used to have to defend coding to people. They'd want to be off in picture-land, drawing OMT (this was before UML) diagrams. And I'd be sitting there saying things like "I don't know. I need to see the code" or "Programming is a form of thinking" or "I don't know what that picture means."

But, now, the shoe's on the other foot. I read some of the XP pages and wind up protesting "There are forms of thinking besides coding." Coding is a very concrete form of thinking. And I think here is value to thinking abstractly on occasion (see ThePotatoSaladAnalogy?). Said value is, I think, given short shrift in the XP universe.

So this is what I find intriguing about XP: the core ideas are straightforward and reasonable. The proponents seem like skilled coders who are reasonably intelligent. And yet... I'm missing something. Why are these people so sure they've got something special ? Apparently the pieces, which I think I understand, fit together in a way I don't understand.

And so I post to the XP pages, trying to understand the stuff. And, as of 8:17 PM PST (but what day?), failing to get it.

-- WilliamGrosso

Interesting that XP comes across as NotDoingDesign, when what I read is only that XP is against BigDesignUpFront. Using CrcCards sounds like XP is doing design, OK not formally documented in a CASE tool. XP seems to be saying TheSourceCodeIsTheDesign, which is a really hot button to judge by the size of that page. -- PeteMcBreen (who updated the first list with #4 through #8)

I think much of the reaction comes against the rhetoric (perhaps sometimes advanced a little...pushily?) rather than the ideas. Like WilliamGrosso and his colleague, I find much of it familiar, and what doesn't match what I practice doesn't for the most part seem wrong to me. Some of the language that looks on the surface like NotDoingDesign rubs me the wrong way, but remember that XP says elsewhere that it does more design than other approaches, so I don't take that at face value.

I think the use of reductionist rhetoric gives a certain StoneSoup quality to the whole thing.

-- JimPerry

Two things that seem to have gotten stepped upon:

1. People who have actually experienced XP find it to be the most enjoyable and productive form of software development they have ever used.
2. If y'all will point out places where we seem to be recommending NotDoingDesign, I'll check 'em out and fix 'em.

It seems that "design" seems to be the center of a lot of contention about XP. I have to say, coming from the shrinkwrap software world, that this seems almost surreal to me. At least in the projects I've been involved in, OMT, UML, and CRC Cards are unheard of. When design is done up front, it's done on white boards or notebook paper. Certainly no persistent design data is kept. These weren't little projects, either. Does everybody in the Smalltalk world obsess over design? Just curious. -- CurtisBartley

Before I ever got into consulting or building business applications, the same was true for me. I came from the shrinkwrap world (even worked at MS at one point) and I never heard of or had to deal with anything but design meetings, e-mail, and whiteboards. These things were communication devices that allowed team to collaborate in the design and development of a product. But these products have different forces that come into play, so that's potentially why emphasis is different and design seems surreal to you.

For example, at Microsoft a developer on the Word team might be thinking about conquering the world -- just joking ;-) -- the developer might be thinking about design regarding page repagination, whereas a developer building a customer management system might be trying to understand an order processing subsystem and may need to communicate with users and technology folks to better understand the business process and use cases.

-- PhilipEskelin

I've noticed in reading many of XP WikiWikiWeb pages that they don't seem to emphasize or reference/compare/contrast with existing work. If this is because XP is so groundbreaking and new that it simply doesn't relate to any existing work, then perhaps people are criticizing it for its methods in order to better understand it and be able to apply it to their own projects.

-- PhilipEskelin

I've been assuming all along that the spirited discussions that come around XP are stimulated by people who are trying to understand. It would be better to compare to other methodologies - as for me I'm not sure how to do that. One way would be for a questioner to say: "In Synchrony we do such and such because of thus and so, how does XP address this?", and we'd try to answer. I think that's what we've been doing anyway, just without the back reference to Synchrony. --RonJeffries

Ron, assuming that you still think that there would be any value in comparing XP with any other method, perhaps tying to fill in the XpFrame (and the other examples of a ProblemFrame) would help? -- KeithBraithwaite

Ferraris are popular - you just don't see many of them. -- ChetHendrickson

Alistair has a very good paper on his Web site, see MethodologySpace, and it attempts to build a vocabulary for comparing methodologies. I also think that he isolates one of the reasons that I like XP so much. Without giving it away, I'll just say that it has to do with fear. -- MichaelFeathers

I like most of XP. And in a situation where I'm building a piece of software unlike any piece of software I've built before, I think it is pretty ideal.

My problem comes because I think it throws away previous domain-specific experience. If I'm building my umpteenth payroll system/object-relational mapping/whatever, then I have a lot of real practical knowledge about the way the future is likely to be. And so the trade-off about YouArentGonnaNeedIt gets skewed. Go look at that page now, and see the arguments against implementing a future feature. If I've been to that future before, then this list looks much less frightening to me. -- DaveCleal

Ran across the phrase stereotyped conceptualization on another page, and liked it. Seems applicable. I currently am working on the third major re-write of a 10 year old system. We have a lot of knowledge about what the current system turned out to be. We also have a lot of domain knowledge - we have developers and other folks who have been in it from the beginning, some of whom have reached respected positions in the field and qualify as domain experts. We have a lot of features and hooks and other garbage in our current system because someone will need this (no-one does).

1. ) None of this tells us the stories our customers will present (the market is changing rapidly- old players are doing business in new ways and there are lots of new players with their own ideas).
2. ) There is an awful lot of junk (that has to be maintained) in the current system because
   • SOMEONE will need it (no-one yet, but we can still hope, right?) and
   • at some point (not now, of course) there was a technical limitation that led to a particular design.

It's nice to have a lot of domain knowledge and experience - it makes answering some questions easy. It doesn't mean I know what I'm going to need this time. I might make better guesses, but do I guess right enough to make it pay off? I've re-written several systems now (systems I was involved in from v0.1), and written the same system more than once. I don't guess well enough the second (or third) time to make it pay off (YMMV). If only users would be happy with the same thing with go-faster stripes on, maybe I'd do better... -- BillJamison

Sure, the hooks you haven't used in ten years should be removed from the new build. Equally, the hooks you used all the time from years 3-10 should go straight into the new build. For me, this kind of "guess" works the second time. Maybe the difference implied in your comment is that your market (what it it?) changes so rapidly and fundamentally that your previous experience is invalid. Which means that we aren't considering the same situation.

(my experiences span process control - physics is quite stable (grin) - systems level software (I'd say pretty stable) - and derivatives trading (and perhaps surprisingly, even there, the basics change at a slower rate than that at which the software gets rewritten)). -- DaveCleal

I don't really agree with the statement above. I've been involved in writing two derivatives trading systems from scratch and worked on two others. The one we're building now incorporates ideas from everything I and co-workers have done previously, sure, but most of the underlying structure is completely new. We have had to fight a lot of people who have pre-conceived ideas about how to build derivatives trading systems "because I did (X) before and it worked". Many people find it very difficult to think past their experience to find new ways of doing things. I'm just as bad as everyone else in this respect by the way.

There are different ways to categorize things, but ultimately there are three reasons WhyXpIsUnpopular:

1. XP says things that people are not willing to accept.

2. People believe that XP says things that they are not willing to accept.

3. That heretic RonJeffries has the audacity to answer questions that people ask him and to defend his beliefs. (Burn him at the stake!)

Ron said ExtremeProgrammingIsNotTheOneTrueFaith. I think there are some that are not satisfied with that. They want a confession that XP is not a True Faith at all. XP says things they are not willing to accept. It can't be a True Faith because it contradicts their True Faith!

Perhaps I am misreading people. I will keep an open mind. I ask that others also keep an open mind. -- KielHodges (wondering if he smells something burning :-)

Open but not uncritical. If there is one strictly rational activity going on in the world today, surely software development is (should ;-) be it. I'm talking about the construction of code artifacts here. And surely being rational means that you don't get to choose what you believe. If the evidence is there, you must accept the claim (modulo the Scientific Method).

A little while ago one presenter of a course on Fagan inspections gave two reasons for using that tool:

• The logic of it is inescapable
• The record shows that it works

For example:

• "It is entirely possible that a large project using XP methodology would never need to go beyond it." on ExtremeProgrammingMayScaleUp
• "Extreme programming quite possibly works in more than one setting," on ExtremeProgramming
• "In XP we rely on the engineer to be doing the right thing, and on pair programming and collective code ownership to pick up the slack. It seems to work ... but does it really?" on ExtremeProgrammingCodeReviews
• "XP has not been tried in larger groups. We believe that the values will surely apply, and that many of the practices will survive. We have no proof." on ExtremeProgrammingInContext
• "I get the impression XP is designed for developing new software...It may be hard...to develop UnitTests for testing modules in isolation, if such modules were never meant to be run in isolation." response: "I suppose in principle this is possible."
• "Could we do PairProgramming across the edges, ...? Perhaps we'd have code ownership by team, ...? Could we still do ContinuousIntegration? How much paperwork could we still not do? " on LargeExtremeProgramming

More hard facts, please. In particular: large projects, projects with large legacies, projects using statically typed languages, any combination of these.

There aren't a large number of XP projects to offer hard data from. Those who need to wait for more data must wait. To aid in understanding and predicting what might happen, we can talk about some of the boundaries, which probably aren't where any of us expect them to be.

What's a large project? XP hasn't been used on projects with large numbers of people. Since it relies on intensive communication, we might expect to modify some of the practices. ChryslerComprehensiveCompensation has over 2,000 classes, 30,000 methods. The project has been ongoing for 30+ months, in production for about 20. Is C3 large?

What's large legacy? C3 is a greenfield system in that all the code we support, we wrote. If a project were extending existing code, full of cruft and poorly tested, that team would have to do something to get it up to the standards XP requires. C3 connects to a very large number of legacy input files and database, and exports to a large number of output files and databases. It handles ASCII files, EBCDIC files, relational gateway, a connection to a commercial tax package written in COBOL, and a connection to a KBMS knowledge-based wage attachment system. Is that a large legacy?

I've used, among others, C and C++ extensively. It is my considered opinion that XP principles, and most of the practices apply just fine to those languages. Slower development cycles, the inability to test everything shortly after implementing - things like these are problematical, IMO.

Hard facts? Emphatically not. Worth discussing? Up to y'all. Start new pages with interesting names and see what happens. --RonJeffries

-- KeithBraithwaite

Point to such if/then statements please. And see the article in the October DistributedComputingMagazine?. Thanks! --RonJeffries

The points above were culled from a quick scan over the pages returned by searching on ExtremeProgramming. I don't have time to do a more thorough search, and don't want to either, since the aim is not to pan XP or it proponents, just to try to elicit some more solid evidence.

I'm happy for you that your green-field, smalltalk IS project was fun and successful. But, if I wanted to start lobbying my management to let me try these techniques (and I might), I'm going to need more.

I'll have to hunt down DistributedComputingMagazine?.

-- KeithBraithwaite

Thanks for the pointers. Most of them seem to be suggestions, possibilities, and beliefs, explicitly so labeled. It would be nice if there were hard data and hard answers. I was concerned that we might actually have asserted that something WAS true where we had insufficient reason. On the other hand, all the crows I have ever seen were black.

As for trying things on projects, it's not like the techniques are so weird or risky that one would need piles of scientific evidence that they work. Perhaps getting permission (or forgiveness) to try them wouldn't have to be such a big deal? -- RonJeffries

I'd like to try ExtremeProgramming on a project but the environment I work in isn't conducive to being extreme.

We need to (try to) provide a formal charter of the work we are going to do before we start. This includes cost and schedule estimates, a very carefully managed specification of the requirements, and a statement of the criteria for the clients acceptance of the project. We work this way not because of any particular development practice dogma but because of the clients business practices.

In this kind of environment it is hard to be Extreme. Maybe the reason WhyXpIsUnpopular is because some developers are jealous that they can't work that way -- or am I wrong and is ExtremeProgramming consistent with this environment?

-- FabianLeGayBrereton

Fabian, you might like to think about what, for want of a better name, I'm calling the ExtremeUnifiedProcess, an unholy wedding of XP, the RationalUnifiedProcess, and the MicrosoftSolutionsFramework that we're attempting at a division of GMAC-RFC called the Asset Resolution Division (ARD). I'll be putting up two docs describing XUP this evening.

In a nutshell, XUP is XP plus whatever parts of RUP you actually need to have the SimplestBusinessThatCouldPossiblyWork. That means that XUP could be full-on ultra-heavy RUP if that's what you're forced to do by your PowersThatBe, but whatever you can get away with, you do, and you work explicitly to lead your business folk towards the XP end of the scale. MSF is kind of tacked-on at the moment, but since the PowersThatBe in my neck of the woods can't bring themselves to buy-in to anything that hasn't got an MS sticker on it, we figure it's better to have it in there than not.

Watch the skies. -- PeterMerel

I would suggest the following reasons for XP to be unpopular.

1. It offloads much of the traditional requirements analysis from the development team to the customer. In many situations, the OnsiteCustomer is not possible; often a single representative of all customer types does not exist. It is usually expected that requirements or UserStories will be determined by the development team during the analysis and design phase. Finally, end customers are not technically savy enough to develop AcceptanceTests.

If they aren't, how are they going to know it works?

WM: The users begin using the system to do their job. At that point they expect the new system to do nearly 100% of what they did with their previous manual procedures.

2. A lot of the terminology is not well defined. It leaves a lot up to the worst fears or best hopes of the reader. I don't feel I can adequately define what Refactoring entails nor the potential scope of UnitTests. I fear the amount of code to be developed for UnitTest may substantially out weigh the amount of application code to be developed.

There's an entire book on Refactoring, that might be a place to start.

As for testing, it seems to be about equal in size to the real code. The way to learn how much to do is to do some amount. If too many defects creep out, do more. If it seems to be taking too long, do less.

WM: This leads to part of my confusion. Sometimes unit testing is defined as 100% testing and testing everything that could possible break (equivalent statements?). Other times it is presented as a subjective call, guess and add tests when and if needed. Does this imply there is a trade off between level of effort and completeness of UnitTests?

3. The benefits of XP to anyone outside the devleopment team are not well defined, nor (as mentioned else where) is there much objective data to rely on. Many of us require more than Try it, you'll like it. as a justification.

What objective data do you have on whatever you're doing now? And what part of predictable incremental delivery of code that is shown to meet requirements doesn't sound like a well-defined benefit?

WM: (Predictable) I am still look for information which shows project tracking info. What were the initial estimates and how did they change over time?

WM: (Incremental Delivery) Incremental delivery is not always a benefit. Our user sites are distributed across the country. Deployment to a single site involves travel costs and time. Deliveries with incomplete functionality also have little interest to our users. They are trying to do their jobs and do not want to do double entry.

WM: (Meets Requirements) This gets back to my initial concern about requirements definition. Basically, our client trusts us and expects us to tease out the requirements. We need to deliver a system that simplifies our users' tasks.

4. The potential for personality conflicts seems overwhelming when using PairProgramming and CollectiveCodeOwnership.

"Seems".

WM: Perhaps I am the only one to have had projects involving people who don't always play well with others. Sometimes I feel I spend more time developing tasking which keeps conflicting personalities apart than tasking to get the job done. Any ideas not involving alcohol or head trauma about how to get people to work together?

This is not intended to be an indictment of XP, it is merely a plea for information. I don't feel I have enough information to make an informed choice; I can only guess what XP might be.

Have you read the books?

WM: So far I have read the xpinstall.pdf download twice cover to cover.

-- WayneMack

I've been following some of the XP discussions and I'm thinking "what the hell kind of software are these guys writing". I'm working on vision systems for factory automation and I just can't see how we could start up an XP project here. I think XP arouses jealousy in people with a RealMenDontWriteBusinessSoftware? attitude and instead of admitting it they try to put it down.

-- Andrew Queisser

I've written real software as well as Business Software, and I'd use XP as it stands for things like compilers and database management systems. For factory automation, I'd start with XP but would expect to need something special to deal with concurrency. For vision, I don't know, never did it. I'd certainly expect PairProgramming, UnitTests, AcceptanceTests, and the PlanningGame to work just fine. What part of XP seems like it wouldn't work? -- RonJeffries

I agree that most the things you mention should work fine, UnitTests maybe being the exception. This is mostly because meaningful tests are hard to set up, primarily because of concurrency, which you already mentioned. AcceptanceTests are even harder because the real acceptance test often can't happen until the production line starts up. (This is when all the engineers stand close to the part they are responsible for while holding their breath and their hand over the E-Stop button.) But the biggest problem is in my opinion that there are simply not enough qualified software engineers in my field. That doesn't mean that they aren't talented or educated - they just happen to be mechanical, chemical, optical, you-name-it engineers. Programming is usually considered a necessary evil and I'm convinced that an XP project can really only be successful when the engineers are at least familiar with the basics of OOP.

I think XP's purist attitude (its resistance to dilution) plus its statement that high benefits are only achieved if it is adopted in its entirety, can make it too big a jump for (some) engineers and enginnering groups. If XP is an 'all or nothing' approach then that is going to make it unpopular. Gradual change is much easier than wholesale. If you are almost doing XP anyway then going the whole way isn't going to be a problem, but if you are nowhere near then you, like me, might wish to discuss MigrationToXp. -- RichardDevelyn

Some of the reasons mentioned here are: 3x5 cards, existing methodologies/roles, and management comfort level.

These can be addressed by quality, supported business software which helps a team do XP. Getting consultants, and training classes is the first step, and I think the next logical one is supporting software (for the whole process, not just the unit testing). Argue if you like, but it's hard to argue with the fact that project managers want to know what's going on in their projects! Who can blame them? When you introduce a new methodology, how can accustomize the non-programmers to it? With these issues in mind, my company is producing quality business software to support the XP process in the most flexible manner possible. (Sorry if this sounds like a commercial, but I really think this kind of thing will be important to gaining more adoption of XP practices!). Check it out at http://www.peerthought.com

-- JamesMcGovern

I have often heard the objection that XpIsCommunism. Anybody else?

This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006