<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.0.1" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: We&#8217;ll Be Agile Later</title>
	<link>http://blog.technoetic.com/2006/09/11/deferred-agility/</link>
	<description></description>
	<pubDate>Tue, 06 Jan 2009 05:19:04 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.1</generator>

	<item>
		<title>by: Steve Donie</title>
		<link>http://blog.technoetic.com/2006/09/11/deferred-agility/#comment-3526</link>
		<pubDate>Thu, 29 Mar 2007 15:36:02 +0000</pubDate>
		<guid>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'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'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'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'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've even heard this referred to as 'design death'. 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-683</link>
		<pubDate>Sun, 17 Sep 2006 21:06:07 +0000</pubDate>
		<guid>http://blog.technoetic.com/2006/09/11/deferred-agility/#comment-683</guid>
					<description>I'm not sure why it'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'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-673</link>
		<pubDate>Sun, 17 Sep 2006 14:10:50 +0000</pubDate>
		<guid>http://blog.technoetic.com/2006/09/11/deferred-agility/#comment-673</guid>
					<description>I didn'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's an important difference, I'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>
