<?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: Is Agile Too Slow?</title>
	<atom:link href="http://www.sarahmei.com/blog/2009/10/06/is-agile-too-slow/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.sarahmei.com/blog/2009/10/06/is-agile-too-slow/</link>
	<description></description>
	<lastBuildDate>Mon, 26 Jul 2010 19:25:56 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Robert Dempsey</title>
		<link>http://www.sarahmei.com/blog/2009/10/06/is-agile-too-slow/comment-page-1/#comment-119</link>
		<dc:creator>Robert Dempsey</dc:creator>
		<pubDate>Thu, 08 Oct 2009 11:18:07 +0000</pubDate>
		<guid isPermaLink="false">http://www.sarahmei.com/blog/?p=214#comment-119</guid>
		<description>@Elisabeth: you bring up a number of great points. Ultimately, every team needs solid engineering practices in place in order to produce a quality product. Many companies don&#039;t have those in place however, and the road to implementation can be a rough one, though it must be traveled to ultimately be successful. So an honest look at the current situation is needed, in addition to a &quot;where do we need to be&quot; assessment. Once you know those two, you can chart a successful course. That course is not a one size fits all solution, which is where folks like you and I come in.</description>
		<content:encoded><![CDATA[<p>@Elisabeth: you bring up a number of great points. Ultimately, every team needs solid engineering practices in place in order to produce a quality product. Many companies don&#8217;t have those in place however, and the road to implementation can be a rough one, though it must be traveled to ultimately be successful. So an honest look at the current situation is needed, in addition to a &#8220;where do we need to be&#8221; assessment. Once you know those two, you can chart a successful course. That course is not a one size fits all solution, which is where folks like you and I come in.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Elisabeth Hendrickson</title>
		<link>http://www.sarahmei.com/blog/2009/10/06/is-agile-too-slow/comment-page-1/#comment-118</link>
		<dc:creator>Elisabeth Hendrickson</dc:creator>
		<pubDate>Thu, 08 Oct 2009 07:06:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.sarahmei.com/blog/?p=214#comment-118</guid>
		<description>In principle I agree: Agile teams adapt practices to fit the business context. They reflect and adjust at regular intervals to improve their overall performance. 

But too often the call to &quot;Adapt the Process to the Context&quot; becomes an excuse. The disciplined engineering practices like Test Driven Development, pairing, and Continuous Integration go by the wayside because &quot;we don&#039;t have time for that here.&quot; Then the organization gets itself into an even bigger mess than before with higher levels of technical debt and an unshippable mess of undocumented spaghetti code. And then they blame Agile. 

Ultimately, Agility can only be assessed by the results: Does the team produce releasable product increments at least once a month, consistently, as a matter of course and without heroics or shortcuts, while adapting to changing business needs? If so, they&#039;re Agile. If not, they aren&#039;t. It&#039;s that simple.

The best way I know to achieve those results is with the disciplined engineering practices that may feel slow initially, the practices that I suspect Obie, Pat, and Tammer were talking about. (I don&#039;t know the others, but I&#039;ve paired with Pat Maddox and that man rocks a keyboard.)

So yes, I am dogmatic about certain practices especially with organizations that are in the process of transitioning and are trying to take shortcuts: the Agile transformation equivalent of get rich quick schemes or miracle diet pills. And no, I won&#039;t work with clients who think it&#039;s just dandy to play whack-a-bug at the end of the development cycle instead of testing throughout.

It&#039;s not that I&#039;m completely inflexible. It&#039;s that as an Agile coach my job is to help clients learn how to be really, truly Agile and not just fool themselves into thinking that they are.</description>
		<content:encoded><![CDATA[<p>In principle I agree: Agile teams adapt practices to fit the business context. They reflect and adjust at regular intervals to improve their overall performance. </p>
<p>But too often the call to &#8220;Adapt the Process to the Context&#8221; becomes an excuse. The disciplined engineering practices like Test Driven Development, pairing, and Continuous Integration go by the wayside because &#8220;we don&#8217;t have time for that here.&#8221; Then the organization gets itself into an even bigger mess than before with higher levels of technical debt and an unshippable mess of undocumented spaghetti code. And then they blame Agile. </p>
<p>Ultimately, Agility can only be assessed by the results: Does the team produce releasable product increments at least once a month, consistently, as a matter of course and without heroics or shortcuts, while adapting to changing business needs? If so, they&#8217;re Agile. If not, they aren&#8217;t. It&#8217;s that simple.</p>
<p>The best way I know to achieve those results is with the disciplined engineering practices that may feel slow initially, the practices that I suspect Obie, Pat, and Tammer were talking about. (I don&#8217;t know the others, but I&#8217;ve paired with Pat Maddox and that man rocks a keyboard.)</p>
<p>So yes, I am dogmatic about certain practices especially with organizations that are in the process of transitioning and are trying to take shortcuts: the Agile transformation equivalent of get rich quick schemes or miracle diet pills. And no, I won&#8217;t work with clients who think it&#8217;s just dandy to play whack-a-bug at the end of the development cycle instead of testing throughout.</p>
<p>It&#8217;s not that I&#8217;m completely inflexible. It&#8217;s that as an Agile coach my job is to help clients learn how to be really, truly Agile and not just fool themselves into thinking that they are.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Robert Dempsey</title>
		<link>http://www.sarahmei.com/blog/2009/10/06/is-agile-too-slow/comment-page-1/#comment-117</link>
		<dc:creator>Robert Dempsey</dc:creator>
		<pubDate>Wed, 07 Oct 2009 12:49:21 +0000</pubDate>
		<guid isPermaLink="false">http://www.sarahmei.com/blog/?p=214#comment-117</guid>
		<description>Great post Sarah. I completely agree. The (product) companies that I work with look to become more agile not necessarily to gain speed of development, but to deal with fluid environments where they have direct contact with their customers who are giving continuous feedback. These companies are leading their industries, and do not want process changes to derail the progress they&#039;ve made. Having said that, they do know and understand that things need to improve process-wise. My job then becomes to ensure that everyone is on the same page with the vision and goals of the company and releases, looking at the current process, and then making that process more agile, taking into consideration existing tools and culture.

Adaptation is the name of the game.</description>
		<content:encoded><![CDATA[<p>Great post Sarah. I completely agree. The (product) companies that I work with look to become more agile not necessarily to gain speed of development, but to deal with fluid environments where they have direct contact with their customers who are giving continuous feedback. These companies are leading their industries, and do not want process changes to derail the progress they&#8217;ve made. Having said that, they do know and understand that things need to improve process-wise. My job then becomes to ensure that everyone is on the same page with the vision and goals of the company and releases, looking at the current process, and then making that process more agile, taking into consideration existing tools and culture.</p>
<p>Adaptation is the name of the game.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark McEahern</title>
		<link>http://www.sarahmei.com/blog/2009/10/06/is-agile-too-slow/comment-page-1/#comment-116</link>
		<dc:creator>Mark McEahern</dc:creator>
		<pubDate>Wed, 07 Oct 2009 03:17:15 +0000</pubDate>
		<guid isPermaLink="false">http://www.sarahmei.com/blog/?p=214#comment-116</guid>
		<description>&quot;If you&#039;re never too slow, you&#039;re never too slow&quot; conveys the same quality/quantity of information as &quot;Agile is never too slow.&quot;

In other words, yes, it&#039;s the wrong question.  But &quot;Agile is never too slow&quot; is also the wrong answer.</description>
		<content:encoded><![CDATA[<p>&#8220;If you&#8217;re never too slow, you&#8217;re never too slow&#8221; conveys the same quality/quantity of information as &#8220;Agile is never too slow.&#8221;</p>
<p>In other words, yes, it&#8217;s the wrong question.  But &#8220;Agile is never too slow&#8221; is also the wrong answer.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jon Larkowski</title>
		<link>http://www.sarahmei.com/blog/2009/10/06/is-agile-too-slow/comment-page-1/#comment-115</link>
		<dc:creator>Jon Larkowski</dc:creator>
		<pubDate>Wed, 07 Oct 2009 01:49:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.sarahmei.com/blog/?p=214#comment-115</guid>
		<description>Exactly! It was difficult to elicit &quot;what does it look like to scale back practices and processes appropriate to context, ROI, opportunity cost, and risk management&quot; at the panel. But that&#039;s where I intended it to head. Not that I minded where the discussion went. As long as the panel spawns a few blog posts and tweets and furthers the agile (little &quot;a&quot;) discussion, I&#039;m happy. Thanks for the post!</description>
		<content:encoded><![CDATA[<p>Exactly! It was difficult to elicit &#8220;what does it look like to scale back practices and processes appropriate to context, ROI, opportunity cost, and risk management&#8221; at the panel. But that&#8217;s where I intended it to head. Not that I minded where the discussion went. As long as the panel spawns a few blog posts and tweets and furthers the agile (little &#8220;a&#8221;) discussion, I&#8217;m happy. Thanks for the post!</p>
]]></content:encoded>
	</item>
</channel>
</rss>
