<?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: That&#8217;s Not Agile!?</title>
	<atom:link href="http://www.leadingagile.com/2012/07/agile/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.leadingagile.com/2012/07/agile/</link>
	<description>Agile Training &#124; Agile Coaching &#124; Agile Transformation &#124; Atlanta, GA &#124; Washington DC &#124; Orlando, FL</description>
	<lastBuildDate>Mon, 20 May 2013 15:20:47 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
	<item>
		<title>By: Mike Cottmeyer</title>
		<link>http://www.leadingagile.com/2012/07/agile/#comment-7978</link>
		<dc:creator>Mike Cottmeyer</dc:creator>
		<pubDate>Wed, 25 Jul 2012 23:26:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.leadingagile.com/?p=1931#comment-7978</guid>
		<description><![CDATA[Great work Matt... thanks for the comment.]]></description>
		<content:encoded><![CDATA[<p>Great work Matt&#8230; thanks for the comment.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: That&#8217;s Not Agile!? &#124; Development Block</title>
		<link>http://www.leadingagile.com/2012/07/agile/#comment-7974</link>
		<dc:creator>That&#8217;s Not Agile!? &#124; Development Block</dc:creator>
		<pubDate>Wed, 25 Jul 2012 12:37:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.leadingagile.com/?p=1931#comment-7974</guid>
		<description><![CDATA[[...] via That&#8217;s Not Agile!?. [...]]]></description>
		<content:encoded><![CDATA[<p>[...] via That&#8217;s Not Agile!?. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Matt Block</title>
		<link>http://www.leadingagile.com/2012/07/agile/#comment-7973</link>
		<dc:creator>Matt Block</dc:creator>
		<pubDate>Wed, 25 Jul 2012 12:33:30 +0000</pubDate>
		<guid isPermaLink="false">http://www.leadingagile.com/?p=1931#comment-7973</guid>
		<description><![CDATA[Great post as always Mike!  I have to agree.  With the last company I worked with this predictability 3-6 months out was the largest benefit we got from agile.  Prior to moving to agile we had no predictability in releases and couldn&#039;t meet any commitments.  Releases were constantly delayed and we never really had great confidence in when a release would happen more than 2 - 4 weeks out.  After we adopted agile we consistently met our release commitments and had high confidence in our dates 3+ months out.]]></description>
		<content:encoded><![CDATA[<p>Great post as always Mike!  I have to agree.  With the last company I worked with this predictability 3-6 months out was the largest benefit we got from agile.  Prior to moving to agile we had no predictability in releases and couldn&#8217;t meet any commitments.  Releases were constantly delayed and we never really had great confidence in when a release would happen more than 2 &#8211; 4 weeks out.  After we adopted agile we consistently met our release commitments and had high confidence in our dates 3+ months out.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike Cottmeyer</title>
		<link>http://www.leadingagile.com/2012/07/agile/#comment-7969</link>
		<dc:creator>Mike Cottmeyer</dc:creator>
		<pubDate>Wed, 25 Jul 2012 02:39:07 +0000</pubDate>
		<guid isPermaLink="false">http://www.leadingagile.com/?p=1931#comment-7969</guid>
		<description><![CDATA[Thanks Sridhar.  It&#039;s a funny balance... if we want to be predictable.... we have to be able to look ahead.  If we want to accommodate constant change... agile can deal with that too... it&#039;s just a different problem.  What I find is that leadership wants teams to be predictable but change everything all the time.  Those two competing needs work against each other and we have to make a strategic decision what kind of organization we want to run... you CANNOT have it both ways.]]></description>
		<content:encoded><![CDATA[<p>Thanks Sridhar.  It&#8217;s a funny balance&#8230; if we want to be predictable&#8230;. we have to be able to look ahead.  If we want to accommodate constant change&#8230; agile can deal with that too&#8230; it&#8217;s just a different problem.  What I find is that leadership wants teams to be predictable but change everything all the time.  Those two competing needs work against each other and we have to make a strategic decision what kind of organization we want to run&#8230; you CANNOT have it both ways.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sridhar</title>
		<link>http://www.leadingagile.com/2012/07/agile/#comment-7962</link>
		<dc:creator>Sridhar</dc:creator>
		<pubDate>Tue, 24 Jul 2012 16:19:31 +0000</pubDate>
		<guid isPermaLink="false">http://www.leadingagile.com/?p=1931#comment-7962</guid>
		<description><![CDATA[Hey Mike

Great post! One of the challenges I often see for product teams is that when marketing decides what features go into releases (this is small, but influential number of IT projects). Marketing folks, while being intelligent and hard working, become fickle-minded when given such freedom (conflicting customer demands, competing products, need to differentiate etc) and start to make changes to the well-understood backlog.

Another challenge are the dependencies of some user stories on other stories - without understanding dependencies and establishing a &quot;platform&quot; of basic features, it becomes very hard for the project team to deliver in a cadence. A DSM can help resolve some (not all, of course) of the dependencies and can contribute to the analysis of the product backlog, thus enhancing the knowledge of the team.]]></description>
		<content:encoded><![CDATA[<p>Hey Mike</p>
<p>Great post! One of the challenges I often see for product teams is that when marketing decides what features go into releases (this is small, but influential number of IT projects). Marketing folks, while being intelligent and hard working, become fickle-minded when given such freedom (conflicting customer demands, competing products, need to differentiate etc) and start to make changes to the well-understood backlog.</p>
<p>Another challenge are the dependencies of some user stories on other stories &#8211; without understanding dependencies and establishing a &#8220;platform&#8221; of basic features, it becomes very hard for the project team to deliver in a cadence. A DSM can help resolve some (not all, of course) of the dependencies and can contribute to the analysis of the product backlog, thus enhancing the knowledge of the team.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
