<?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"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Good Agile, Bad Agile (Conversation)</title>
	<atom:link href="http://blog.lab49.com/archives/676/feed" rel="self" type="application/rss+xml" />
	<link>http://blog.lab49.com/archives/676</link>
	<description>Technology and industry insights from Lab49.</description>
	<lastBuildDate>Wed,  2 Dec 2009 13:01:54 -0500</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: The Emperor’s New Code &#187; Good Agile, Bad Agile</title>
		<link>http://blog.lab49.com/archives/676/comment-page-1#comment-80704</link>
		<dc:creator>The Emperor’s New Code &#187; Good Agile, Bad Agile</dc:creator>
		<pubDate>Sun, 26 Aug 2007 06:10:29 +0000</pubDate>
		<guid isPermaLink="false">http://blog.lab49.com/?p=676#comment-80704</guid>
		<description>[...] My Lab 49 colleague Nick Robinson posted some excerpts from an email exchange we had about Agile Development on the company blog yesterday, and I&#8217;ve reproduced his excerpts here as well: [...]</description>
		<content:encoded><![CDATA[<p>[...] My Lab 49 colleague Nick Robinson posted some excerpts from an email exchange we had about Agile Development on the company blog yesterday, and I&#8217;ve reproduced his excerpts here as well: [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: The Emperor&#8217;s New Code &#187; Good Agile, Bad Agile</title>
		<link>http://blog.lab49.com/archives/676/comment-page-1#comment-58844</link>
		<dc:creator>The Emperor&#8217;s New Code &#187; Good Agile, Bad Agile</dc:creator>
		<pubDate>Fri, 01 Jun 2007 18:53:30 +0000</pubDate>
		<guid isPermaLink="false">http://blog.lab49.com/?p=676#comment-58844</guid>
		<description>[...] My Lab 49 colleague Nick Robinson posted some excerpts from an email exchange we had about Agile Development on the company blog yesterday, and I&#8217;ve reproduced his excerpts here as well: [...]</description>
		<content:encoded><![CDATA[<p>[...] My Lab 49 colleague Nick Robinson posted some excerpts from an email exchange we had about Agile Development on the company blog yesterday, and I&#8217;ve reproduced his excerpts here as well: [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: BF3 &#187; Good Agile, Bad Agile</title>
		<link>http://blog.lab49.com/archives/676/comment-page-1#comment-47191</link>
		<dc:creator>BF3 &#187; Good Agile, Bad Agile</dc:creator>
		<pubDate>Thu, 26 Apr 2007 16:46:14 +0000</pubDate>
		<guid isPermaLink="false">http://blog.lab49.com/?p=676#comment-47191</guid>
		<description>[...] My Lab49 colleg Nick Robinson posted some excerpts from an email exchange we had about Agile Development on the company blog yesterday at http://blog.lab49.com/?p=676. I&#8217;ve reproduced his excerpts here as well:  Bruce, [...]</description>
		<content:encoded><![CDATA[<p>[...] My Lab49 colleg Nick Robinson posted some excerpts from an email exchange we had about Agile Development on the company blog yesterday at <a href="http://blog.lab49.com/?p=676" rel="nofollow">http://blog.lab49.com/?p=676</a>. I&#8217;ve reproduced his excerpts here as well:  Bruce, [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: BF3 &#187; Good Agile, Bad Agile</title>
		<link>http://blog.lab49.com/archives/676/comment-page-1#comment-47189</link>
		<dc:creator>BF3 &#187; Good Agile, Bad Agile</dc:creator>
		<pubDate>Thu, 26 Apr 2007 16:44:21 +0000</pubDate>
		<guid isPermaLink="false">http://blog.lab49.com/?p=676#comment-47189</guid>
		<description>[...] My Lab49 colleg Nick Robinson posted some excerpts from an email exchange we had about Agile Development on the company blog yesterday at http://blog.lab49.com/?p=676. I&#8217;ve reproduced his excerpts here as well: [...]</description>
		<content:encoded><![CDATA[<p>[...] My Lab49 colleg Nick Robinson posted some excerpts from an email exchange we had about Agile Development on the company blog yesterday at <a href="http://blog.lab49.com/?p=676" rel="nofollow">http://blog.lab49.com/?p=676</a>. I&#8217;ve reproduced his excerpts here as well: [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nick</title>
		<link>http://blog.lab49.com/archives/676/comment-page-1#comment-6816</link>
		<dc:creator>Nick</dc:creator>
		<pubDate>Sat, 28 Oct 2006 21:46:35 +0000</pubDate>
		<guid isPermaLink="false">http://blog.lab49.com/?p=676#comment-6816</guid>
		<description>Hi Darren,

I agreee, building the wrong system is useless, irrespective of the design behind its creation.  My challenge to you is your assertion that &quot;Software is too easy these days&quot; and that &quot;design is too well understood&quot;.  These are both in the dimension of software construction, and neither address your important issue of business and requirements analysis to make sure we know we are building the right system.

To me, software today is even harder than it was 5 years ago, irrespective of what I know I know now.  At the same time I am agreeing with you regarding the benefits of building software in an agile fashion.  Our goals are to deliver to the users.  Our ability to do so is in the quality of the code we write as practitioners.</description>
		<content:encoded><![CDATA[<p>Hi Darren,</p>
<p>I agreee, building the wrong system is useless, irrespective of the design behind its creation.  My challenge to you is your assertion that &#8220;Software is too easy these days&#8221; and that &#8220;design is too well understood&#8221;.  These are both in the dimension of software construction, and neither address your important issue of business and requirements analysis to make sure we know we are building the right system.</p>
<p>To me, software today is even harder than it was 5 years ago, irrespective of what I know I know now.  At the same time I am agreeing with you regarding the benefits of building software in an agile fashion.  Our goals are to deliver to the users.  Our ability to do so is in the quality of the code we write as practitioners.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Darren Oakey</title>
		<link>http://blog.lab49.com/archives/676/comment-page-1#comment-6785</link>
		<dc:creator>Darren Oakey</dc:creator>
		<pubDate>Fri, 27 Oct 2006 23:45:31 +0000</pubDate>
		<guid isPermaLink="false">http://blog.lab49.com/?p=676#comment-6785</guid>
		<description>I&#039;ve worked in a lot of &quot;traditional&quot; environments, and a lot of agile environments.  I&#039;ve seen a few projects succeed, and a lot of projects &quot;fail&quot;.

And one thing I notice is missing from a lot of the agile/non-agile discussions, and I think people are often missing the important point...

IT&#039;S ALL ABOUT THE USERS

I&#039;ve seen perfect systems be designed and built - truly works of art... and for various political or economic reasons - never get turned on.  I&#039;ve seen huge projects fail terribly, or tiny fun hacks turn into massively productive systems - and as far as the process goes, I have only one conclusion...

If your user&#039;s complain about a problem - and it&#039;s fixed the next day... you are doing something right.  If it&#039;s not, you are doing something wrong.

Software is too easy these days, design is too well understood - the tools are too good and software structures exist that produce lightning fast, rock solid and reuseable code the first time.

Really, in this day and age, I reckon it all comes down to that.... if you don&#039;t release solid, reliable business benefits to your customers every week, then you aren&#039;t doing the right stuff... 

and generally, I think &quot;agile&quot; methodologies are the only ways I know of of satisfying that requirement.  In the old days we&#039;d take a month designing the future system.  Nowadays we can build it in a week, and it will be superceded by something much better in three months... at the end of the day, the old software processes just can&#039;t keep up.</description>
		<content:encoded><![CDATA[<p>I&#8217;ve worked in a lot of &#8220;traditional&#8221; environments, and a lot of agile environments.  I&#8217;ve seen a few projects succeed, and a lot of projects &#8220;fail&#8221;.</p>
<p>And one thing I notice is missing from a lot of the agile/non-agile discussions, and I think people are often missing the important point&#8230;</p>
<p>IT&#8217;S ALL ABOUT THE USERS</p>
<p>I&#8217;ve seen perfect systems be designed and built &#8211; truly works of art&#8230; and for various political or economic reasons &#8211; never get turned on.  I&#8217;ve seen huge projects fail terribly, or tiny fun hacks turn into massively productive systems &#8211; and as far as the process goes, I have only one conclusion&#8230;</p>
<p>If your user&#8217;s complain about a problem &#8211; and it&#8217;s fixed the next day&#8230; you are doing something right.  If it&#8217;s not, you are doing something wrong.</p>
<p>Software is too easy these days, design is too well understood &#8211; the tools are too good and software structures exist that produce lightning fast, rock solid and reuseable code the first time.</p>
<p>Really, in this day and age, I reckon it all comes down to that&#8230;. if you don&#8217;t release solid, reliable business benefits to your customers every week, then you aren&#8217;t doing the right stuff&#8230; </p>
<p>and generally, I think &#8220;agile&#8221; methodologies are the only ways I know of of satisfying that requirement.  In the old days we&#8217;d take a month designing the future system.  Nowadays we can build it in a week, and it will be superceded by something much better in three months&#8230; at the end of the day, the old software processes just can&#8217;t keep up.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
