Examples: * IndustrialExtremeProgramming As a few people are saying on the mailing list, this is an attempt at branding XP. IOW taking a free ride off the hard work the community has put into building up XP and making XP better, and creating a brand to benefit a select few. The founders must be well aware that the implication of the name to any non-XPer will be that XP is nice, but if you want the real deal you gotta go with IndustrialExtremeProgramming? (in spite of IXP statements to the contrary - which IMO is just to placate the mainstream XP'ers). If this were really an honest attempt at improving XP, no new group or website or mailing list would be necessary - a simple new category at wiki with these subtopics in it would be all that was needed. But that requires ExtremeHumility - not a hidden agenda of increasing your hourly consulting rates. ---- It could be said that ExtremeHumility can never be an attribute of any founding member. When one is too close they will attempt to stifle innovation so as to not give up control. Maybe if ExtremeProgramming had a certification body that had equal representation amongst both consulting firms and large enterprises who have nothing to sell then balance is achieved. KentBeck ---- I disagree profoundly with the thesis of this page. Given that XP is not the last word in the evolution of software processes, it has to be possible to create methodologies that are similar to but distinguishable from XP. These methodologies will require names. If I define a mutant form of XP that throws out some practices and adds others (perhaps XP for large distributed teams) then I should give it a different name rather than pretending I'm still doing XP. This way, people will know that I'm ''not'' doing XP but something else. ''See AreYouDoingXp'' People are extending and mutating XP in all sorts of interesting ways to deal with environments where the process described in the white book isn't currently suitable. If we're not to devalue the name of XP then offshoots that serve different purposes should be given different names. Otherwise we'll end up with something like the (Rational) Unified Process where so much is optional that it's hard to tell who is actually practicing it properly. We have to ask if XP is a family of processes (like Crystal) or one customizable process (like (R)UP)? If it's a family then it's okay for different members to have different names.If it's one process then there's no point branding the different configurations. -- AdewaleOshineye ''So we define a new wiki category called IndustrialXpPractices, transfer everything over from industrialxp.org to subtopics under that category, scrap the industrial xp mailing list and talk about these things through the normal xp channels.'' ''That it's been done so many times this way makes IndustrialXp stick out like a sore thumb (or rather, the motivations behind its existence).'' If it really is a different method derived from XP, then I think it's fair to borrow the name XP. That happens all the time in academic circles. If it's simply slapping the name on something completely unrelated, or something completely identical to XP, then I'd say that's an attempt at XP branding, and to be discouraged. XP is definitely exclusive in nature. If you're doing something sorta like XP, but not exactly, then you can't say that you're "doing XP" (see AlmostExtremeProgramming, XpLite, PrettyAdventuresomeProgramming). There are good reasons for this, and I personally believe this is why XP has out-grown other AgileProcesses. IndustrialLogic has been around for a while experimenting with XP, and contributing to its development, so I don't think we can fault them if they believe they have made a genuine improvement to XP. Only time will tell if they're right, and in the mean time, XP is safe in its exclusivity cocoon. -- Not Affiliated with IndustrialLogic ---- I think KentBeck addressed the question well just after the public announcement of IndustrialExtremeProgramming: : The most interesting question at this point to me is whether IXP embodies and strengthens the values we hold dear. If it does not, it threatens to weaken our community. If IXP is consistent with XP values (as I think it is), then it is likely to serve to strengthen our community. -- ''Kent Beck'' : (Context: http://groups.yahoo.com/group/extremeprogramming/message/72551) In fact, IXP does embody and strengthen these values. I've yet to hear anyone suggest to the contrary. -- RussRufer This page has been around for a while and is all the sudden getting a ton of edits. I may have been a little harsh back when I originally wrote this (**now that's an understatement!**) (I would in particular refactor out the possibly anti-capitalist tone), but I stand by the gist of it. You guys wisely realize that you can't really create a brand around something that's already so much in the public domain (or for the sake of argument, let's say KentBeck et al already "own" the brand). You have to differentiate yourselves. I understand all the business reasons behind that, and I guess I'd just say that I hope you all make a lot of money but mostly stay off the radar for the sake of maintaining a common front/consistent message. XP is already a tough sell as it is, and taken too far this just makes it look like we're forking IMHO. ---- IXP is easier to sell than XP because it addresses management. -- JoshuaKerievsky Don't use XP for management, use the ScrumProcess instead. Scrum and XP work great together. Does Scrum include test-driven management? ''No.'' I don't know, but I doubt it (since I don't know what test-driven management is). Scrum management may not have the same practices as Industrial XP, but that may not be a bad thing. It ''is'' derived from AgilePrinciples such as continuous feedback and using-what-works. For instance, it is the ScrumMaster'''''''s responsibility to deal with the blocking issues raised during the DailyScrum and to report back to the team what has been done about them. To learn more about Test-Driven Management, go here: http://www.industrialxp.org/description.html#test-driven_management. -- JoshuaKerievsky