<?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 for The Bovine Synchrotron</title>
	<atom:link href="http://bovon.org/index.php/comments/feed" rel="self" type="application/rss+xml" />
	<link>http://bovon.org</link>
	<description>Cow collisions in Farmer Higgs&#039; field - James Lewis&#039; blog</description>
	<lastBuildDate>Sun, 22 Jan 2012 18:57:29 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.1</generator>
	<item>
		<title>Comment on Upcoming talk on building micro services by Andy Palmer</title>
		<link>http://bovon.org/index.php/archives/263/comment-page-1#comment-195</link>
		<dc:creator>Andy Palmer</dc:creator>
		<pubDate>Sun, 22 Jan 2012 18:57:29 +0000</pubDate>
		<guid isPermaLink="false">http://bovon.org/index.php/archives/263#comment-195</guid>
		<description>This sounds awesome. We should pair on something sometime soon (that isn&#039;t a service for rates)</description>
		<content:encoded><![CDATA[<p>This sounds awesome. We should pair on something sometime soon (that isn&#8217;t a service for rates)</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Why your organisation won&#8217;t be agile &#8211; Part I by Rapunzel’s Ivory Tower &#124; The Agile Radar</title>
		<link>http://bovon.org/index.php/archives/108/comment-page-1#comment-192</link>
		<dc:creator>Rapunzel’s Ivory Tower &#124; The Agile Radar</dc:creator>
		<pubDate>Mon, 12 Dec 2011 15:07:47 +0000</pubDate>
		<guid isPermaLink="false">http://bovon.org/?p=108#comment-192</guid>
		<description>[...] James Lewis recognized some of these challenges. (but was perhaps more brutal than my insider view) [...]</description>
		<content:encoded><![CDATA[<p>[...] James Lewis recognized some of these challenges. (but was perhaps more brutal than my insider view) [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Why your organisation won&#8217;t be agile &#8211; Part I by Rapunzel's Ivory Tower &#124; The Agile Pirate</title>
		<link>http://bovon.org/index.php/archives/108/comment-page-1#comment-188</link>
		<dc:creator>Rapunzel's Ivory Tower &#124; The Agile Pirate</dc:creator>
		<pubDate>Tue, 13 Sep 2011 18:41:07 +0000</pubDate>
		<guid isPermaLink="false">http://bovon.org/?p=108#comment-188</guid>
		<description>[...] James Lewis recognized some of these challenges. (but was perhaps more brutal than my insider view) [...]</description>
		<content:encoded><![CDATA[<p>[...] James Lewis recognized some of these challenges. (but was perhaps more brutal than my insider view) [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Agile Brazil and ThoughtWorks, Porto Alegre by Rafael Noronha</title>
		<link>http://bovon.org/index.php/archives/234/comment-page-1#comment-145</link>
		<dc:creator>Rafael Noronha</dc:creator>
		<pubDate>Thu, 01 Jul 2010 23:40:00 +0000</pubDate>
		<guid isPermaLink="false">http://bovon.org/?p=234#comment-145</guid>
		<description>Nice talk at #AgileBrazil.

Keep up on sharing agile adoption experiences!</description>
		<content:encoded><![CDATA[<p>Nice talk at #AgileBrazil.</p>
<p>Keep up on sharing agile adoption experiences!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on With measurement comes control by Michael Norton</title>
		<link>http://bovon.org/index.php/archives/207/comment-page-1#comment-86</link>
		<dc:creator>Michael Norton</dc:creator>
		<pubDate>Tue, 16 Mar 2010 15:47:56 +0000</pubDate>
		<guid isPermaLink="false">http://bovon.org/?p=207#comment-86</guid>
		<description>James:

Very good post. Visibility can be a detriment in the wrong organization. Trust is critical and abuse of an open environment can destroy that rust.

Keep it up.</description>
		<content:encoded><![CDATA[<p>James:</p>
<p>Very good post. Visibility can be a detriment in the wrong organization. Trust is critical and abuse of an open environment can destroy that rust.</p>
<p>Keep it up.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on BCS &#8211; SPA talk on Agile Adoption Anti-patterns &#8211; March 3rd by kash</title>
		<link>http://bovon.org/index.php/archives/87/comment-page-1#comment-77</link>
		<dc:creator>kash</dc:creator>
		<pubDate>Thu, 04 Mar 2010 18:28:29 +0000</pubDate>
		<guid isPermaLink="false">http://bovon.org/?p=87#comment-77</guid>
		<description>will the slides be posted online?</description>
		<content:encoded><![CDATA[<p>will the slides be posted online?</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Why your organisation won&#8217;t be agile &#8211; Part I by Anonymous Coward</title>
		<link>http://bovon.org/index.php/archives/108/comment-page-1#comment-41</link>
		<dc:creator>Anonymous Coward</dc:creator>
		<pubDate>Wed, 17 Feb 2010 00:50:16 +0000</pubDate>
		<guid isPermaLink="false">http://bovon.org/?p=108#comment-41</guid>
		<description>What&#039;s wrong with Golf Course Agile? It&#039;s a simple truth that not every organization is prepared for (or will succeed with) self-organizing teams, pair programming, etc. 

Having said that, I would suggest that ALL software development organizations will benefit from visibility, predictability, repeatability, and dare I say *Software Production Management*</description>
		<content:encoded><![CDATA[<p>What&#8217;s wrong with Golf Course Agile? It&#8217;s a simple truth that not every organization is prepared for (or will succeed with) self-organizing teams, pair programming, etc. </p>
<p>Having said that, I would suggest that ALL software development organizations will benefit from visibility, predictability, repeatability, and dare I say *Software Production Management*</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Why your organisation won&#8217;t be agile &#8211; Part I by james</title>
		<link>http://bovon.org/index.php/archives/108/comment-page-1#comment-38</link>
		<dc:creator>james</dc:creator>
		<pubDate>Mon, 15 Feb 2010 09:27:36 +0000</pubDate>
		<guid isPermaLink="false">http://bovon.org/?p=108#comment-38</guid>
		<description>Hey Robert - glad you enjoyed the post. You are absolutely correct in this - and this is certainly one of the failure modes for projects that I see. How can you expect people to execute something they have never seen work? I&#039;m going to talk about this a bit more in my next post I think.</description>
		<content:encoded><![CDATA[<p>Hey Robert &#8211; glad you enjoyed the post. You are absolutely correct in this &#8211; and this is certainly one of the failure modes for projects that I see. How can you expect people to execute something they have never seen work? I&#8217;m going to talk about this a bit more in my next post I think.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Why your organisation won&#8217;t be agile &#8211; Part I by MyWeeklyLinks &#8211; Week 6 &#171; Ole Morten Amundsen</title>
		<link>http://bovon.org/index.php/archives/108/comment-page-1#comment-35</link>
		<dc:creator>MyWeeklyLinks &#8211; Week 6 &#171; Ole Morten Amundsen</dc:creator>
		<pubDate>Sun, 14 Feb 2010 15:16:40 +0000</pubDate>
		<guid isPermaLink="false">http://bovon.org/?p=108#comment-35</guid>
		<description>[...] Why your organisation won’t be agile Attacking mainstream agile. Or, really, the mainstream implementation of [...]</description>
		<content:encoded><![CDATA[<p>[...] Why your organisation won’t be agile Attacking mainstream agile. Or, really, the mainstream implementation of [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Why your organisation won&#8217;t be agile &#8211; Part I by Robert Reppel</title>
		<link>http://bovon.org/index.php/archives/108/comment-page-1#comment-33</link>
		<dc:creator>Robert Reppel</dc:creator>
		<pubDate>Sat, 13 Feb 2010 15:27:12 +0000</pubDate>
		<guid isPermaLink="false">http://bovon.org/?p=108#comment-33</guid>
		<description>I find that keeping a project in &quot;pull&quot; mode instead slipping back into &quot;push&quot; is an ongoing struggle: The need for (perceived) security and predictability constantly railroads folks into the direction of making a &quot;traditional&quot; project plan with tasks broken down and assigned several weeks in advance and written-in-stone dates where a set of specified-in-advance features need to be available. 

Indeed, courage seems to be the least fashionable part of Agile, for very good reasons: The &quot;traditional&quot; way to run a project feels intuitive to most managers because they usually have never seen anything that works better. They rightly think that using no project plan at all will lead to chaos. By comparison, getting one&#039;s ducks in a row by waterfall planning and assigning tasks in advance will work much better. Ergo, projects fail because not enough of that was done. These are deeply held convictions, seemingly backed up by experience. Building a case for doing things differently can be a livelihood-threatening exercise. When management mandates agile practices it&#039;s far safer to go the Scrummerfall or &quot;Cargo Cult Agile&quot; route instead.</description>
		<content:encoded><![CDATA[<p>I find that keeping a project in &#8220;pull&#8221; mode instead slipping back into &#8220;push&#8221; is an ongoing struggle: The need for (perceived) security and predictability constantly railroads folks into the direction of making a &#8220;traditional&#8221; project plan with tasks broken down and assigned several weeks in advance and written-in-stone dates where a set of specified-in-advance features need to be available. </p>
<p>Indeed, courage seems to be the least fashionable part of Agile, for very good reasons: The &#8220;traditional&#8221; way to run a project feels intuitive to most managers because they usually have never seen anything that works better. They rightly think that using no project plan at all will lead to chaos. By comparison, getting one&#8217;s ducks in a row by waterfall planning and assigning tasks in advance will work much better. Ergo, projects fail because not enough of that was done. These are deeply held convictions, seemingly backed up by experience. Building a case for doing things differently can be a livelihood-threatening exercise. When management mandates agile practices it&#8217;s far safer to go the Scrummerfall or &#8220;Cargo Cult Agile&#8221; route instead.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

