<?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: Waterfalling your Iterations: Not the way to handle re-work</title>
	<atom:link href="http://www.agilecoach.ca/2010/01/15/waterfalling-your-iterations-not-the-way-to-handle-re-work/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.agilecoach.ca/2010/01/15/waterfalling-your-iterations-not-the-way-to-handle-re-work/</link>
	<description>Understand. Educate. Execute. Reflect.</description>
	<lastBuildDate>Mon, 26 Jul 2010 17:55:19 -0400</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Mishkin Berteig</title>
		<link>http://www.agilecoach.ca/2010/01/15/waterfalling-your-iterations-not-the-way-to-handle-re-work/comment-page-1/#comment-98</link>
		<dc:creator>Mishkin Berteig</dc:creator>
		<pubDate>Fri, 15 Jan 2010 19:02:12 +0000</pubDate>
		<guid isPermaLink="false">http://www.agilecoach.ca/?p=137#comment-98</guid>
		<description>Hi Jason,  Just thought I would share a little elaboration on your statement that re-work is unavoidable (which I agree with fully!)

Re-work is a consequence of change: changing environment, changing understanding, and changing foundations.  Re-work accumulates as a result of these changes.  The only questions is when and how we handle re-work.  Typically, in the old model, re-work is handled by batching it up as long as possible (until everyone is groaning under the strain of accommodating change).  This is often seen in large IT projects when the organization changes technologies (e.g. Mainframe to Client-Server to ... to ...).

Agile pushes teams and organizations to handle re-work in much smaller pieces.  This is hard at first!  However, by doing it frequently, it makes people good at it... which means that quality and speed improve.</description>
		<content:encoded><![CDATA[<p>Hi Jason,  Just thought I would share a little elaboration on your statement that re-work is unavoidable (which I agree with fully!)</p>
<p>Re-work is a consequence of change: changing environment, changing understanding, and changing foundations.  Re-work accumulates as a result of these changes.  The only questions is when and how we handle re-work.  Typically, in the old model, re-work is handled by batching it up as long as possible (until everyone is groaning under the strain of accommodating change).  This is often seen in large IT projects when the organization changes technologies (e.g. Mainframe to Client-Server to &#8230; to &#8230;).</p>
<p>Agile pushes teams and organizations to handle re-work in much smaller pieces.  This is hard at first!  However, by doing it frequently, it makes people good at it&#8230; which means that quality and speed improve.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
