<?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: We&#8217;ll Be Agile Later</title>
	<atom:link href="http://blog.technoetic.com/2006/09/11/deferred-agility/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.technoetic.com/2006/09/11/deferred-agility/</link>
	<description></description>
	<lastBuildDate>Thu, 24 Mar 2011 04:59:14 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
	<item>
		<title>By: Steve Donie</title>
		<link>http://blog.technoetic.com/2006/09/11/deferred-agility/comment-page-1/#comment-3526</link>
		<dc:creator>Steve Donie</dc:creator>
		<pubDate>Thu, 29 Mar 2007 15:36:02 +0000</pubDate>
		<guid isPermaLink="false">http://blog.technoetic.com/2006/09/11/deferred-agility/#comment-3526</guid>
		<description>One thing to pay particular attention to in the article is this quote near the end:

&quot;It&#039;s now a month later and progress has slowed to a crawl. In the first month, we were adding significant new features every week, sometimes every day. What happened?

In two words: technical debt. To make progress so quickly, we cut a lot of corners. We didn&#039;t implement any tests. We only programmed for the best-case networking scenarios. We let bugs creep in.&quot;

Progress slowed to a crawl. Because they didn&#039;t have unit tests, it was getting harder and harder to add new features. So while it may be slower to add a new feature using TDD, the overall velocity of the project remains more constant. 

It&#039;s like the old joke about the guy painting the stripe down the middle of the road. The first day he paints one mile of stripe, and the boss is super-pleased. The next day though, he only paints a quarter-mile. The boss asks what happened to slow him down so much, and he says he keeps getting farther away from the paint bucket. The more debt you take on, the slower you go. I&#039;ve even heard this referred to as &#039;design death&#039;. http://kanemar.com/2006/07/23/technical-debt-and-the-death-of-design-part-1/</description>
		<content:encoded><![CDATA[<p>One thing to pay particular attention to in the article is this quote near the end:</p>
<p>&#8220;It&#8217;s now a month later and progress has slowed to a crawl. In the first month, we were adding significant new features every week, sometimes every day. What happened?</p>
<p>In two words: technical debt. To make progress so quickly, we cut a lot of corners. We didn&#8217;t implement any tests. We only programmed for the best-case networking scenarios. We let bugs creep in.&#8221;</p>
<p>Progress slowed to a crawl. Because they didn&#8217;t have unit tests, it was getting harder and harder to add new features. So while it may be slower to add a new feature using TDD, the overall velocity of the project remains more constant. </p>
<p>It&#8217;s like the old joke about the guy painting the stripe down the middle of the road. The first day he paints one mile of stripe, and the boss is super-pleased. The next day though, he only paints a quarter-mile. The boss asks what happened to slow him down so much, and he says he keeps getting farther away from the paint bucket. The more debt you take on, the slower you go. I&#8217;ve even heard this referred to as &#8216;design death&#8217;. <a href="http://kanemar.com/2006/07/23/technical-debt-and-the-death-of-design-part-1/" rel="nofollow">http://kanemar.com/2006/07/23/technical-debt-and-the-death-of-design-part-1/</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Steve Bate</title>
		<link>http://blog.technoetic.com/2006/09/11/deferred-agility/comment-page-1/#comment-683</link>
		<dc:creator>Steve Bate</dc:creator>
		<pubDate>Sun, 17 Sep 2006 21:06:07 +0000</pubDate>
		<guid isPermaLink="false">http://blog.technoetic.com/2006/09/11/deferred-agility/#comment-683</guid>
		<description>I&#039;m not sure why it&#039;s an important difference. My experience is that there is a close relationship between application of agile practices and continuous learning and adaptation. In any case, the learning overhead would generally be higher for a non-agile team so Jame&#039;s argument to postpone using agile practices would seem to apply to a team like that even more than for an agile practitioner with his experience.</description>
		<content:encoded><![CDATA[<p>I&#8217;m not sure why it&#8217;s an important difference. My experience is that there is a close relationship between application of agile practices and continuous learning and adaptation. In any case, the learning overhead would generally be higher for a non-agile team so Jame&#8217;s argument to postpone using agile practices would seem to apply to a team like that even more than for an agile practitioner with his experience.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ilja Preuss</title>
		<link>http://blog.technoetic.com/2006/09/11/deferred-agility/comment-page-1/#comment-673</link>
		<dc:creator>Ilja Preuss</dc:creator>
		<pubDate>Sun, 17 Sep 2006 14:10:50 +0000</pubDate>
		<guid isPermaLink="false">http://blog.technoetic.com/2006/09/11/deferred-agility/#comment-673</guid>
		<description>I didn&#039;t understand James to say that *applying* Agile practices (particularly testing) would have slowed them down, but *learning* how to apply them in their situation. That&#039;s an important difference, I&#039;d think.</description>
		<content:encoded><![CDATA[<p>I didn&#8217;t understand James to say that *applying* Agile practices (particularly testing) would have slowed them down, but *learning* how to apply them in their situation. That&#8217;s an important difference, I&#8217;d think.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

