<?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: Limping through agile</title>
	<atom:link href="http://www.klocwork.com/blog/2010/01/limping-through-agile/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.klocwork.com/blog/2010/01/limping-through-agile/?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=limping-through-agile</link>
	<description>&#62;kloctalk is a blog and a community for software development professionals who create and maintain mission-critical software and the challenges they face on a daily basis.</description>
	<lastBuildDate>Tue, 24 Jan 2012 14:57:13 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
	<item>
		<title>By: Patti Murphy</title>
		<link>http://www.klocwork.com/blog/2010/01/limping-through-agile/comment-page-1/#comment-1089</link>
		<dc:creator>Patti Murphy</dc:creator>
		<pubDate>Fri, 22 Jan 2010 17:07:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.klocwork.com/blog/?p=635#comment-1089</guid>
		<description>Hi Melody,

I&#039;m pleased to hear that your experiences have been so positive.

Geographically-dispersed teams can make things even more difficult. A number of our developers are based in Russia, but they&#039;re prompt in answering e-mail inquiries and providing examples.

I typically haven&#039;t gotten enough to write about from iteration planning meetings, just a general notion of what&#039;s coming up. With &quot;feature flux&quot;,  it seems that you can only give a general &quot;what-this-is&quot; statement instead of &quot;how it works&quot; because the latter can change quite a bit. Often, our focus starts with &quot;why you&#039;d want to use this&quot; and then go from there.

In my limited agile experience,  new products have been easier to document than new features to existing products. With the former, &lt;a href=&quot;http://www.klocwork.com/blog/?p=465&quot; rel=&quot;nofollow&quot;&gt; workflow&lt;/a&gt; is more readily available.

Thanks for your perspective.</description>
		<content:encoded><![CDATA[<p>Hi Melody,</p>
<p>I&#8217;m pleased to hear that your experiences have been so positive.</p>
<p>Geographically-dispersed teams can make things even more difficult. A number of our developers are based in Russia, but they&#8217;re prompt in answering e-mail inquiries and providing examples.</p>
<p>I typically haven&#8217;t gotten enough to write about from iteration planning meetings, just a general notion of what&#8217;s coming up. With &#8220;feature flux&#8221;,  it seems that you can only give a general &#8220;what-this-is&#8221; statement instead of &#8220;how it works&#8221; because the latter can change quite a bit. Often, our focus starts with &#8220;why you&#8217;d want to use this&#8221; and then go from there.</p>
<p>In my limited agile experience,  new products have been easier to document than new features to existing products. With the former, <a href="http://www.klocwork.com/blog/?p=465" rel="nofollow"> workflow</a> is more readily available.</p>
<p>Thanks for your perspective.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Melody Locke</title>
		<link>http://www.klocwork.com/blog/2010/01/limping-through-agile/comment-page-1/#comment-1083</link>
		<dc:creator>Melody Locke</dc:creator>
		<pubDate>Thu, 21 Jan 2010 20:38:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.klocwork.com/blog/?p=635#comment-1083</guid>
		<description>I’ve been working in agile environments since early 2005 and found it to be a refreshing change from waterfall. I think that the developers and testers had more challenges, but after they settled down with the new methodology, my life was pretty good. In waterfall I had to use specs that were out-of-date the moment they were finished. I followed those documents, while my developers use them as guidelines. As you might guess, rewriting was a big part of my life in this scenario. 

As for the “big picture,” that should be addressed in release planning. At the end of a successful release-planning meeting, I had a pretty good idea about what would be developed and where (in the release cycle) the work would occur. I know that many writing groups trail their development counterparts, but I’ve been a part of good teams where I was able to write content and have it tested during the development iteration. 

Not all of my agile experiences have been as good as my first. Now my developers are located on the other side of the world, which makes staying current with development is bit challenging.</description>
		<content:encoded><![CDATA[<p>I’ve been working in agile environments since early 2005 and found it to be a refreshing change from waterfall. I think that the developers and testers had more challenges, but after they settled down with the new methodology, my life was pretty good. In waterfall I had to use specs that were out-of-date the moment they were finished. I followed those documents, while my developers use them as guidelines. As you might guess, rewriting was a big part of my life in this scenario. </p>
<p>As for the “big picture,” that should be addressed in release planning. At the end of a successful release-planning meeting, I had a pretty good idea about what would be developed and where (in the release cycle) the work would occur. I know that many writing groups trail their development counterparts, but I’ve been a part of good teams where I was able to write content and have it tested during the development iteration. </p>
<p>Not all of my agile experiences have been as good as my first. Now my developers are located on the other side of the world, which makes staying current with development is bit challenging.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

