<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: XP as Over-Reaction (Redux)</title>
	<atom:link href="http://barelyenough.org/blog/2005/04/xp-as-over-reaction-redux/feed/" rel="self" type="application/rss+xml" />
	<link>http://barelyenough.org/blog/2005/04/xp-as-over-reaction-redux/</link>
	<description></description>
	<pubDate>Tue, 06 Jan 2009 21:58:38 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5</generator>
		<item>
		<title>By: Peter Williams</title>
		<link>http://barelyenough.org/blog/2005/04/xp-as-over-reaction-redux/#comment-5</link>
		<dc:creator>Peter Williams</dc:creator>
		<pubDate>Wed, 20 Apr 2005 20:18:31 +0000</pubDate>
		<guid isPermaLink="false">http://pezra.barelyenough.org/wordpress/?p=90#comment-5</guid>
		<description>&lt;p&gt;I think the lightweight vs. heavyweight is a reasonable criteria, though not the only one,  on which to base comparisons of methodologies these days.  Most modern methodologies basically accept that software development projects cannot be effectively predicted.  I know of no one who thinks water fall methodologies work, so we have won this battle.&lt;/p&gt;

&lt;p&gt;But among the remaining methodologies what differentiates them?  For me the primary feature of XP is that it attempts avoid all unnecessary work.  To the point that it modifies really basic processes, like requirements gathering and coding.  I am all for avoiding unnecessary work, but I think it is worth thinking critically about whether each particular bit of work is really unnecessary or not.&lt;/p&gt;

&lt;p&gt;To be clear, my post was specified targeted at XP, not agile methodologies in general.  On the whole I prefer agile methodologies.  I just think XP might be a little too extreme.&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>I think the lightweight vs. heavyweight is a reasonable criteria, though not the only one,  on which to base comparisons of methodologies these days.  Most modern methodologies basically accept that software development projects cannot be effectively predicted.  I know of no one who thinks water fall methodologies work, so we have won this battle.</p>
<p>But among the remaining methodologies what differentiates them?  For me the primary feature of XP is that it attempts avoid all unnecessary work.  To the point that it modifies really basic processes, like requirements gathering and coding.  I am all for avoiding unnecessary work, but I think it is worth thinking critically about whether each particular bit of work is really unnecessary or not.</p>
<p>To be clear, my post was specified targeted at XP, not agile methodologies in general.  On the whole I prefer agile methodologies.  I just think XP might be a little too extreme.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Darren Oakey</title>
		<link>http://barelyenough.org/blog/2005/04/xp-as-over-reaction-redux/#comment-4</link>
		<dc:creator>Darren Oakey</dc:creator>
		<pubDate>Wed, 20 Apr 2005 19:10:36 +0000</pubDate>
		<guid isPermaLink="false">http://pezra.barelyenough.org/wordpress/?p=90#comment-4</guid>
		<description>&lt;p&gt;I would strongly disagree.   To me, there is far more of a fundamental difference between XP and waterfall than there is between XP-as-lightweight compared to heavyweight methodologies.&lt;/p&gt;

&lt;p&gt;Documentation, processes... all of that is fairly irrelevant compared to the main thrust of any agile process, as compared to bad- [oh sorry - I mean] -traditional processes&lt;/p&gt;

&lt;p&gt;Traditional processes work on the assumption that it is POSSIBLE to predict the course of a software development.&lt;/p&gt;

&lt;p&gt;It is not.   And it's not a surprise that more than 95% of all software projects fail.&lt;/p&gt;

&lt;p&gt;The fundamental, and only really important tenet of all agile processes is they toss that [stupid] assumption, and say "requirements, directions, plans, acceptance, timelines, resources and everything else can and will change throughout the project - let's set up a structure to deal with it"&lt;/p&gt;
</description>
		<content:encoded><![CDATA[<p>I would strongly disagree.   To me, there is far more of a fundamental difference between XP and waterfall than there is between XP-as-lightweight compared to heavyweight methodologies.</p>
<p>Documentation, processes&#8230; all of that is fairly irrelevant compared to the main thrust of any agile process, as compared to bad- [oh sorry - I mean] -traditional processes</p>
<p>Traditional processes work on the assumption that it is POSSIBLE to predict the course of a software development.</p>
<p>It is not.   And it&#8217;s not a surprise that more than 95% of all software projects fail.</p>
<p>The fundamental, and only really important tenet of all agile processes is they toss that [stupid] assumption, and say &#8220;requirements, directions, plans, acceptance, timelines, resources and everything else can and will change throughout the project - let&#8217;s set up a structure to deal with it&#8221;</p>
]]></content:encoded>
	</item>
</channel>
</rss>
