<?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: Four Types of Resistors When Adopting Agile</title>
	<atom:link href="http://blog.mountaingoatsoftware.com/four-types-of-resistors-when-adopting-agile/feed" rel="self" type="application/rss+xml" />
	<link>http://blog.mountaingoatsoftware.com/four-types-of-resistors-when-adopting-agile</link>
	<description>Succeeding With Agile®</description>
	<lastBuildDate>Fri, 10 Feb 2012 03:51:54 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Mike Cohn</title>
		<link>http://blog.mountaingoatsoftware.com/four-types-of-resistors-when-adopting-agile/comment-page-1#comment-134238</link>
		<dc:creator>Mike Cohn</dc:creator>
		<pubDate>Fri, 14 Jan 2011 02:33:21 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mountaingoatsoftware.com/?p=413#comment-134238</guid>
		<description>Hi Denise--
Going &quot;all in&quot; can work extremely well but the stars need to be aligned. I have clients who do it and, while usually successful, it&#039;s always scary at first. In many cases, an incremental &quot;Start Small&quot; approach works best. Good luck with the transition.</description>
		<content:encoded><![CDATA[<p>Hi Denise&#8211;<br />
Going &#8220;all in&#8221; can work extremely well but the stars need to be aligned. I have clients who do it and, while usually successful, it&#8217;s always scary at first. In many cases, an incremental &#8220;Start Small&#8221; approach works best. Good luck with the transition.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Denise</title>
		<link>http://blog.mountaingoatsoftware.com/four-types-of-resistors-when-adopting-agile/comment-page-1#comment-134187</link>
		<dc:creator>Denise</dc:creator>
		<pubDate>Thu, 13 Jan 2011 22:52:59 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mountaingoatsoftware.com/?p=413#comment-134187</guid>
		<description>I am reading your book &quot;Succeeding with Agile&quot;. Our team is bringing in Agile but using the &quot;Start Small&quot; approach this time. Previously I worked with a group that tried the &quot;All Out&quot; approach but it didn&#039;t work because many on the team were not using any of the agile practices prior to being told they were going to be using scrum.</description>
		<content:encoded><![CDATA[<p>I am reading your book &#8220;Succeeding with Agile&#8221;. Our team is bringing in Agile but using the &#8220;Start Small&#8221; approach this time. Previously I worked with a group that tried the &#8220;All Out&#8221; approach but it didn&#8217;t work because many on the team were not using any of the agile practices prior to being told they were going to be using scrum.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Madhan</title>
		<link>http://blog.mountaingoatsoftware.com/four-types-of-resistors-when-adopting-agile/comment-page-1#comment-116297</link>
		<dc:creator>Madhan</dc:creator>
		<pubDate>Wed, 24 Nov 2010 10:41:40 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mountaingoatsoftware.com/?p=413#comment-116297</guid>
		<description>Thanks for your reply, Mike.  

Infact, I am trying the iteration concept now.  But, I doubt that introducing iteration alone will make much difference as the supporting practices for iteration are lacking.  This will eventually kill iteration pilot pointing that it was a failure (or lack of success thereof).

We ultimately want to add more processes to ensure that nothing goes wrong rather than amplifying learning opportunities from mistakes.

I would differ from your view that moving to agile from no process is easier. If at all we have tried traditional methods and suffered due to them, I could atleast show them as case studies to promote agile.  When I show outside case studies, they are brushed aside as &quot;Doesn&#039;t fit to us&quot; answers.</description>
		<content:encoded><![CDATA[<p>Thanks for your reply, Mike.  </p>
<p>Infact, I am trying the iteration concept now.  But, I doubt that introducing iteration alone will make much difference as the supporting practices for iteration are lacking.  This will eventually kill iteration pilot pointing that it was a failure (or lack of success thereof).</p>
<p>We ultimately want to add more processes to ensure that nothing goes wrong rather than amplifying learning opportunities from mistakes.</p>
<p>I would differ from your view that moving to agile from no process is easier. If at all we have tried traditional methods and suffered due to them, I could atleast show them as case studies to promote agile.  When I show outside case studies, they are brushed aside as &#8220;Doesn&#8217;t fit to us&#8221; answers.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike Cohn</title>
		<link>http://blog.mountaingoatsoftware.com/four-types-of-resistors-when-adopting-agile/comment-page-1#comment-114442</link>
		<dc:creator>Mike Cohn</dc:creator>
		<pubDate>Thu, 18 Nov 2010 04:30:25 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mountaingoatsoftware.com/?p=413#comment-114442</guid>
		<description>Hi Madhan--
I&#039;d suggest asking them whey not start with the approach (agile) that more and more companies are moving toward. The big shift over the last 10 years has been in that direction. If other companies are moving to, I&#039;d want them to explain why they shouldn&#039;t also be. Also, the move to agile from no process is easier than moving to agile from a strict waterfall/sequential process.  The other thing to do is to tell them it&#039;s easier to try and they should just give it a try for two weeks (one sprint/iteration). If they don&#039;t see the merits after that, they can stop. So the worst that can happen is two weeks get completely thrown away and that is a very unlikely worst case.</description>
		<content:encoded><![CDATA[<p>Hi Madhan&#8211;<br />
I&#8217;d suggest asking them whey not start with the approach (agile) that more and more companies are moving toward. The big shift over the last 10 years has been in that direction. If other companies are moving to, I&#8217;d want them to explain why they shouldn&#8217;t also be. Also, the move to agile from no process is easier than moving to agile from a strict waterfall/sequential process.  The other thing to do is to tell them it&#8217;s easier to try and they should just give it a try for two weeks (one sprint/iteration). If they don&#8217;t see the merits after that, they can stop. So the worst that can happen is two weeks get completely thrown away and that is a very unlikely worst case.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Madhan</title>
		<link>http://blog.mountaingoatsoftware.com/four-types-of-resistors-when-adopting-agile/comment-page-1#comment-114279</link>
		<dc:creator>Madhan</dc:creator>
		<pubDate>Wed, 17 Nov 2010 14:51:30 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mountaingoatsoftware.com/?p=413#comment-114279</guid>
		<description>Hi Mike,

I&#039;ve read your book and since then I&#039;ve been promoting agile in my organization.  The problem here is, my organization is mostly ad-hoc in handling projects.  They have burned their fingers more than once because of this approach and are now bent upon to move towards a &quot;structured&quot; methodology similar to waterfall.  So, my rants on why waterfall is wrong doesn&#039;t ring a bell to them.  They counter by saying that lets first learn the traditional way of doing things and then talk about agile.  I am out of ideas :(</description>
		<content:encoded><![CDATA[<p>Hi Mike,</p>
<p>I&#8217;ve read your book and since then I&#8217;ve been promoting agile in my organization.  The problem here is, my organization is mostly ad-hoc in handling projects.  They have burned their fingers more than once because of this approach and are now bent upon to move towards a &#8220;structured&#8221; methodology similar to waterfall.  So, my rants on why waterfall is wrong doesn&#8217;t ring a bell to them.  They counter by saying that lets first learn the traditional way of doing things and then talk about agile.  I am out of ideas <img src='http://blog.mountaingoatsoftware.com/wp-includes/images/smilies/icon_sad.gif' alt=':(' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Christophe</title>
		<link>http://blog.mountaingoatsoftware.com/four-types-of-resistors-when-adopting-agile/comment-page-1#comment-71997</link>
		<dc:creator>Christophe</dc:creator>
		<pubDate>Sun, 11 Apr 2010 20:07:41 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mountaingoatsoftware.com/?p=413#comment-71997</guid>
		<description>Having tried to transition with Agile for 2 customers, I believe the main resistance is from managers. To quote S. Covey &quot;managers do the things right; leaders do the right thing&quot;: the main reason why Agile may not work is when dealing with managers who want to follow processes so they do the things right (processes lead projects). Leaders don&#039;t care too much about doing the things right until they believe they are doing into the right direction. Then and only then, they care about doing the things right. With managers, even going into the wrong direction, as long as they are doing the things right, they will continue and reject changes. Waterfall is a management methodology as opposed to Agile that is a leadership methodology I believe.</description>
		<content:encoded><![CDATA[<p>Having tried to transition with Agile for 2 customers, I believe the main resistance is from managers. To quote S. Covey &#8220;managers do the things right; leaders do the right thing&#8221;: the main reason why Agile may not work is when dealing with managers who want to follow processes so they do the things right (processes lead projects). Leaders don&#8217;t care too much about doing the things right until they believe they are doing into the right direction. Then and only then, they care about doing the things right. With managers, even going into the wrong direction, as long as they are doing the things right, they will continue and reject changes. Waterfall is a management methodology as opposed to Agile that is a leadership methodology I believe.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Erik Buitenhuis</title>
		<link>http://blog.mountaingoatsoftware.com/four-types-of-resistors-when-adopting-agile/comment-page-1#comment-61670</link>
		<dc:creator>Erik Buitenhuis</dc:creator>
		<pubDate>Thu, 17 Dec 2009 11:22:14 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mountaingoatsoftware.com/?p=413#comment-61670</guid>
		<description>@Jeemy Ranwick,

It could well be that the team members that like waterfall for its predictability just don&#039;t get confronted with the negative çonsequences of waterfall. They are quite comfortable in their role, doing their job delivering software according to the specifications. In many waterfall companies team members will never know whether or not the end-result meets the client&#039;s business goals and probably won&#039;t care. They&#039;re happily locked in their (developer?) role. 
This attitude is very much a personality and cultural thing and the team members are definitely in the follower quadrant in the article above. 

-erik</description>
		<content:encoded><![CDATA[<p>@Jeemy Ranwick,</p>
<p>It could well be that the team members that like waterfall for its predictability just don&#8217;t get confronted with the negative çonsequences of waterfall. They are quite comfortable in their role, doing their job delivering software according to the specifications. In many waterfall companies team members will never know whether or not the end-result meets the client&#8217;s business goals and probably won&#8217;t care. They&#8217;re happily locked in their (developer?) role.<br />
This attitude is very much a personality and cultural thing and the team members are definitely in the follower quadrant in the article above. </p>
<p>-erik</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff Smith</title>
		<link>http://blog.mountaingoatsoftware.com/four-types-of-resistors-when-adopting-agile/comment-page-1#comment-60753</link>
		<dc:creator>Jeff Smith</dc:creator>
		<pubDate>Mon, 07 Dec 2009 17:16:52 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mountaingoatsoftware.com/?p=413#comment-60753</guid>
		<description>Perfect :-)

I tend to be a voracious reader - but missed these so far. Maybe I add them to my Christmas list. Also, thanks for the clarification on your position... I hope we can be successful along these lines. 

Raising the industry capability, helping people drive great quality and product... Getting all that branding out of the way would definitely help. 

Jeff</description>
		<content:encoded><![CDATA[<p>Perfect <img src='http://blog.mountaingoatsoftware.com/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> </p>
<p>I tend to be a voracious reader &#8211; but missed these so far. Maybe I add them to my Christmas list. Also, thanks for the clarification on your position&#8230; I hope we can be successful along these lines. </p>
<p>Raising the industry capability, helping people drive great quality and product&#8230; Getting all that branding out of the way would definitely help. </p>
<p>Jeff</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike Cohn</title>
		<link>http://blog.mountaingoatsoftware.com/four-types-of-resistors-when-adopting-agile/comment-page-1#comment-60668</link>
		<dc:creator>Mike Cohn</dc:creator>
		<pubDate>Sun, 06 Dec 2009 16:22:08 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mountaingoatsoftware.com/?p=413#comment-60668</guid>
		<description>Jeff-
If you&#039;ll take a look through the Succeeding with Agile book you will see that I am hardly a religious zealot unwilling to consider other viewpoints. In fact, I struggled a long time with even putting &quot;Scrum&quot; in the subtitle of the book because for years I have been making the point that I am in favor of &quot;unbranded agile.&quot; 

I&#039;m also on record as saying I want agile to go away. In the same sense that no one says &quot;I need to go to the object-oriented design meeting at 9am&quot; (they just call it a &quot;design meeting&quot;) I&#039;m anxious for the time when we can stop talking about agile entirely. For more on that see the interview of me in &lt;a href=&quot;http://www.amazon.com/exec/obidos/ASIN/0596518021/mountaingoats-20&quot; rel=&quot;nofollow&quot;&gt;Beautiful Teams: Inspiring and Cautionary Tales from Veteran Team Leaders&lt;/a&gt; by Andrew Stellman and Jennifer Greene.</description>
		<content:encoded><![CDATA[<p>Jeff-<br />
If you&#8217;ll take a look through the Succeeding with Agile book you will see that I am hardly a religious zealot unwilling to consider other viewpoints. In fact, I struggled a long time with even putting &#8220;Scrum&#8221; in the subtitle of the book because for years I have been making the point that I am in favor of &#8220;unbranded agile.&#8221; </p>
<p>I&#8217;m also on record as saying I want agile to go away. In the same sense that no one says &#8220;I need to go to the object-oriented design meeting at 9am&#8221; (they just call it a &#8220;design meeting&#8221;) I&#8217;m anxious for the time when we can stop talking about agile entirely. For more on that see the interview of me in <a href="http://www.amazon.com/exec/obidos/ASIN/0596518021/mountaingoats-20" rel="nofollow">Beautiful Teams: Inspiring and Cautionary Tales from Veteran Team Leaders</a> by Andrew Stellman and Jennifer Greene.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jeff Smith</title>
		<link>http://blog.mountaingoatsoftware.com/four-types-of-resistors-when-adopting-agile/comment-page-1#comment-60665</link>
		<dc:creator>Jeff Smith</dc:creator>
		<pubDate>Sun, 06 Dec 2009 15:51:05 +0000</pubDate>
		<guid isPermaLink="false">http://blog.mountaingoatsoftware.com/?p=413#comment-60665</guid>
		<description>In the world of debate, always contrasting Waterfall and Scrum(or &quot;agile&quot; which denotes no process in particular) is called a strawman - choosing your opposing case, whether it is real or not, to solidify your own position. I have been in software development 20 years (Over a dozen companies - most being command performances), and I have yet to see true waterfall.  I also have yet to see true Scrum. What I have seen are good and bad process, good and bad practitioners, and a lot of people telling others how to act. Lately I have seen a lot of religion and saluting. Iterative development has been around a very long time - most of the tools pitched by agile pundits are not new inventions; The big difference I see is an overwelming dedication to staying myopic and anti-anything that does not salute the manifesto. I have seen four-hour CMMI level 3 cycle time, birth to live data center production deployment; I have seen 500 man-year projects reduced to 2 man-years, using methods nowhere in the agile doctrine. And to suggest that you can sustainably delivery quality functionality at speed using anything else has the pundits insulting your heritage and screaming the dogma louder. I believe in the tools found across the agile world - I don&#039;t believe I should have to talk Agile versus Fragile, YAGNI, and so on. I have a big problem with the religion of agile; And I have a problem with those who choose not to see. Perhaps some resistors actually have found something worth looking at - will Scrum allow for that? If it won&#039;t - it is religion; It is yet another form of process naziism. Any frenzy, mob, or groupthink needs to exposed for what it is - Professionalism means staying objective. I also have a little problem with weak understanding of human Pschology; More Weinberg please. ITIL - not really a process - but a reference library of practices - sort of; You can do bad ITIL just like you can do bad Scrum. Which takes where I was going - quit trying to implement Scrum and do what works; If the methods of Scrum get you there - great... Perhape some of the &quot;resistors&quot; just don&#039;t like religion.</description>
		<content:encoded><![CDATA[<p>In the world of debate, always contrasting Waterfall and Scrum(or &#8220;agile&#8221; which denotes no process in particular) is called a strawman &#8211; choosing your opposing case, whether it is real or not, to solidify your own position. I have been in software development 20 years (Over a dozen companies &#8211; most being command performances), and I have yet to see true waterfall.  I also have yet to see true Scrum. What I have seen are good and bad process, good and bad practitioners, and a lot of people telling others how to act. Lately I have seen a lot of religion and saluting. Iterative development has been around a very long time &#8211; most of the tools pitched by agile pundits are not new inventions; The big difference I see is an overwelming dedication to staying myopic and anti-anything that does not salute the manifesto. I have seen four-hour CMMI level 3 cycle time, birth to live data center production deployment; I have seen 500 man-year projects reduced to 2 man-years, using methods nowhere in the agile doctrine. And to suggest that you can sustainably delivery quality functionality at speed using anything else has the pundits insulting your heritage and screaming the dogma louder. I believe in the tools found across the agile world &#8211; I don&#8217;t believe I should have to talk Agile versus Fragile, YAGNI, and so on. I have a big problem with the religion of agile; And I have a problem with those who choose not to see. Perhaps some resistors actually have found something worth looking at &#8211; will Scrum allow for that? If it won&#8217;t &#8211; it is religion; It is yet another form of process naziism. Any frenzy, mob, or groupthink needs to exposed for what it is &#8211; Professionalism means staying objective. I also have a little problem with weak understanding of human Pschology; More Weinberg please. ITIL &#8211; not really a process &#8211; but a reference library of practices &#8211; sort of; You can do bad ITIL just like you can do bad Scrum. Which takes where I was going &#8211; quit trying to implement Scrum and do what works; If the methods of Scrum get you there &#8211; great&#8230; Perhape some of the &#8220;resistors&#8221; just don&#8217;t like religion.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

