<?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: Agile and Lean Software Development &#8211; an Oxymoron?</title>
	<atom:link href="http://www.rallydev.com/agileblog/2009/06/agile-and-lean-software-development-an-oxymoron/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.rallydev.com/agileblog/2009/06/agile-and-lean-software-development-an-oxymoron/</link>
	<description>Adopt, Scale and Succeed with Agile Development</description>
	<lastBuildDate>Wed, 17 Mar 2010 14:33:06 -0600</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Are XP and Agile Lean? (Part 1) &#171; Scaling Software Agility</title>
		<link>http://www.rallydev.com/agileblog/2009/06/agile-and-lean-software-development-an-oxymoron/#comment-4116</link>
		<dc:creator>Are XP and Agile Lean? (Part 1) &#171; Scaling Software Agility</dc:creator>
		<pubDate>Fri, 02 Oct 2009 20:39:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.rallydev.com/agileblog/?p=2427#comment-4116</guid>
		<description>[...] to me.  Many others do to. For example, Ryan Martens recently blogged on the topic at Agile and Lean Software Development &#8211; an Oxymoron?  However, some of the experts comments he received back were not so [...]</description>
		<content:encoded><![CDATA[<p>[...] to me.  Many others do to. For example, Ryan Martens recently blogged on the topic at Agile and Lean Software Development &#8211; an Oxymoron?  However, some of the experts comments he received back were not so [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: robertclaye</title>
		<link>http://www.rallydev.com/agileblog/2009/06/agile-and-lean-software-development-an-oxymoron/#comment-3577</link>
		<dc:creator>robertclaye</dc:creator>
		<pubDate>Sat, 18 Jul 2009 10:28:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.rallydev.com/agileblog/?p=2427#comment-3577</guid>
		<description>good blog.... Agile has evolved both bottom-up and top-down based on the evolution in technology infrastructure, tools and guiding ideas of our industry. It is symbolized by increased productivity, speed to market, response to change and craftsmanship.</description>
		<content:encoded><![CDATA[<p>good blog&#8230;. Agile has evolved both bottom-up and top-down based on the evolution in technology infrastructure, tools and guiding ideas of our industry. It is symbolized by increased productivity, speed to market, response to change and craftsmanship.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike Alber</title>
		<link>http://www.rallydev.com/agileblog/2009/06/agile-and-lean-software-development-an-oxymoron/#comment-3547</link>
		<dc:creator>Mike Alber</dc:creator>
		<pubDate>Mon, 06 Jul 2009 15:22:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.rallydev.com/agileblog/?p=2427#comment-3547</guid>
		<description>For those interested in further discussion of this topic, check out the discussion thread in the&lt;a href=&quot;http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&amp;gid=37631&amp;discussionID=4622307&amp;sik=1246893722165&amp;trk=ug_qa_q&amp;goback=%2Eana_37631_1246893722165_3_1&quot; rel=&quot;nofollow&quot;&gt; Agile Alliance LinkedIn group
&lt;/a&gt;
</description>
		<content:encoded><![CDATA[<p>For those interested in further discussion of this topic, check out the discussion thread in the<a href="http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&#038;gid=37631&#038;discussionID=4622307&#038;sik=1246893722165&#038;trk=ug_qa_q&#038;goback=%2Eana_37631_1246893722165_3_1" rel="nofollow"> Agile Alliance LinkedIn group<br />
</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jay Conne</title>
		<link>http://www.rallydev.com/agileblog/2009/06/agile-and-lean-software-development-an-oxymoron/#comment-3528</link>
		<dc:creator>Jay Conne</dc:creator>
		<pubDate>Fri, 26 Jun 2009 19:08:21 +0000</pubDate>
		<guid isPermaLink="false">http://www.rallydev.com/agileblog/?p=2427#comment-3528</guid>
		<description>I agree with Kent and see the varied Agile components as complementary.  In my training and consulting I present the principles and practices from Lean, Scrum and XP as contributing different dimensions of a complete solution.  I posted my summary definitions to achieve this at: 
http://www.jconne.com/agile1whatisit/</description>
		<content:encoded><![CDATA[<p>I agree with Kent and see the varied Agile components as complementary.  In my training and consulting I present the principles and practices from Lean, Scrum and XP as contributing different dimensions of a complete solution.  I posted my summary definitions to achieve this at:<br />
<a href="http://www.jconne.com/agile1whatisit/" rel="nofollow">http://www.jconne.com/agile1whatisit/</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Chuck van der Linden</title>
		<link>http://www.rallydev.com/agileblog/2009/06/agile-and-lean-software-development-an-oxymoron/#comment-3524</link>
		<dc:creator>Chuck van der Linden</dc:creator>
		<pubDate>Thu, 25 Jun 2009 23:12:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.rallydev.com/agileblog/?p=2427#comment-3524</guid>
		<description>Ryan

F. Agile and Lean are not the same, but are more alike than they are different.
G. You can&#039;t accurately distill complicated concepts like Agile and Lean down to simple multple choice &#039;soundbyte&#039; answers.
H. All generalizations are false.

That said, of all the great comments above, I find I agree the most with Kent&#039;s</description>
		<content:encoded><![CDATA[<p>Ryan</p>
<p>F. Agile and Lean are not the same, but are more alike than they are different.<br />
G. You can&#8217;t accurately distill complicated concepts like Agile and Lean down to simple multple choice &#8217;soundbyte&#8217; answers.<br />
H. All generalizations are false.</p>
<p>That said, of all the great comments above, I find I agree the most with Kent&#8217;s</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Siddharta</title>
		<link>http://www.rallydev.com/agileblog/2009/06/agile-and-lean-software-development-an-oxymoron/#comment-3520</link>
		<dc:creator>Siddharta</dc:creator>
		<pubDate>Wed, 24 Jun 2009 08:57:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.rallydev.com/agileblog/?p=2427#comment-3520</guid>
		<description>Ryan,

I think it depends on what problem we are trying to solve. 

Are we trying to streamline the flow, eliminate waste and remove bottlenecks? Then Lean principles can help.

Are we trying to develop products in an uncertain environment, with unstable and changing requirements? Then Agile principles can help.

Are we trying to do both? Then adapt both principles.

As I see it, Lean and Agile are independent, but can both help from a software delivery standpoint depending on what you are trying to achieve.</description>
		<content:encoded><![CDATA[<p>Ryan,</p>
<p>I think it depends on what problem we are trying to solve. </p>
<p>Are we trying to streamline the flow, eliminate waste and remove bottlenecks? Then Lean principles can help.</p>
<p>Are we trying to develop products in an uncertain environment, with unstable and changing requirements? Then Agile principles can help.</p>
<p>Are we trying to do both? Then adapt both principles.</p>
<p>As I see it, Lean and Agile are independent, but can both help from a software delivery standpoint depending on what you are trying to achieve.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike Dwyer</title>
		<link>http://www.rallydev.com/agileblog/2009/06/agile-and-lean-software-development-an-oxymoron/#comment-3517</link>
		<dc:creator>Mike Dwyer</dc:creator>
		<pubDate>Tue, 23 Jun 2009 20:13:42 +0000</pubDate>
		<guid isPermaLink="false">http://www.rallydev.com/agileblog/?p=2427#comment-3517</guid>
		<description>Ryan
Great post. I am more closely aligned with Kent&#039;s comment but I don&#039;t think he goes far enough in drawing the distinction.  I cant agree with him that one is the subset of the other as IMO they address two orthogonal environments, But let me take a stab at it.  
Lean finds it roots in refining known, predictable, and measurable activities. It is easily linked to cost and consumption and has seen many incantations ranging from MTM (manual time and motion) to JIT, Dependent Demand Algorithms and Queue theory.  They all work within their strengths and fail terribly when there is little or bad data to work with.  They are horrible in trying to do something new.
Agile has come from Emergent Solutions, Complex Adaptive Systems and Chaos theory.  In a sense it is closely aligned with exploratory research.  It works best with new stuff, having the discipline to frequently review and evaluate the impact and value of the work and then to adjust not only the work but the goal being worked toward.  It starts having problems when there is a lot known about the task, there is good data to compare and contrast past efforts with current situations.

It is important to keep in mind that both can work in the other&#039;s area, but why would you consciously pick the wrong one for the what you were doing.</description>
		<content:encoded><![CDATA[<p>Ryan<br />
Great post. I am more closely aligned with Kent&#8217;s comment but I don&#8217;t think he goes far enough in drawing the distinction.  I cant agree with him that one is the subset of the other as IMO they address two orthogonal environments, But let me take a stab at it.<br />
Lean finds it roots in refining known, predictable, and measurable activities. It is easily linked to cost and consumption and has seen many incantations ranging from MTM (manual time and motion) to JIT, Dependent Demand Algorithms and Queue theory.  They all work within their strengths and fail terribly when there is little or bad data to work with.  They are horrible in trying to do something new.<br />
Agile has come from Emergent Solutions, Complex Adaptive Systems and Chaos theory.  In a sense it is closely aligned with exploratory research.  It works best with new stuff, having the discipline to frequently review and evaluate the impact and value of the work and then to adjust not only the work but the goal being worked toward.  It starts having problems when there is a lot known about the task, there is good data to compare and contrast past efforts with current situations.</p>
<p>It is important to keep in mind that both can work in the other&#8217;s area, but why would you consciously pick the wrong one for the what you were doing.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ryan Martens</title>
		<link>http://www.rallydev.com/agileblog/2009/06/agile-and-lean-software-development-an-oxymoron/#comment-3516</link>
		<dc:creator>Ryan Martens</dc:creator>
		<pubDate>Tue, 23 Jun 2009 17:00:53 +0000</pubDate>
		<guid isPermaLink="false">http://www.rallydev.com/agileblog/?p=2427#comment-3516</guid>
		<description>Great comments everyone, Thanks!  I am really trying to understand the taxonomy and develop our own theories around these to concepts.

Maybe a multiple choice question would be better than strict advocacy on the concept of &quot;instance?&quot;  I did not sell everyone:)

A. Agile and Lean are different/oxymoron 
B. Agile is for software teams and Lean is for executives and manufacturing
C. Agile and Lean are both empirical processes, not plan driven
D. Agile is template extension of Lean without the waste elimination and with heavy emphasis on customer feedback
E. Agile is an instance of Lean for Software Development teams (Kanban is Agile and Lean)</description>
		<content:encoded><![CDATA[<p>Great comments everyone, Thanks!  I am really trying to understand the taxonomy and develop our own theories around these to concepts.</p>
<p>Maybe a multiple choice question would be better than strict advocacy on the concept of &#8220;instance?&#8221;  I did not sell everyone:)</p>
<p>A. Agile and Lean are different/oxymoron<br />
B. Agile is for software teams and Lean is for executives and manufacturing<br />
C. Agile and Lean are both empirical processes, not plan driven<br />
D. Agile is template extension of Lean without the waste elimination and with heavy emphasis on customer feedback<br />
E. Agile is an instance of Lean for Software Development teams (Kanban is Agile and Lean)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott Jackson</title>
		<link>http://www.rallydev.com/agileblog/2009/06/agile-and-lean-software-development-an-oxymoron/#comment-3515</link>
		<dc:creator>Scott Jackson</dc:creator>
		<pubDate>Tue, 23 Jun 2009 16:55:52 +0000</pubDate>
		<guid isPermaLink="false">http://www.rallydev.com/agileblog/?p=2427#comment-3515</guid>
		<description>Thanks for the clarification.  I am still working with these concepts at a theoretical level.  My current work has us locked into a very ordered development process (Waterfall), which in the past has worked well for our customer and the types of products we are developing.  The part that kills our current schedules is obviously change, especially in requirements.  I am more familiar with the Agile/Scrum methodology then Lean.  My point above stems from the fact that Lean strives to reduce waste, but couldn’t waste occur in requirement change with  overproduction, extra processing, and waiting? 

I definitely see how the two processes are similar and I can see how the concept of “pull” relates to the Agile principles.  Not to beat a dead horse, but isn’t the Lean Practitioner’s view of pull different from the Agile Practitioner’s principle of “welcoming change” late in the development process?   According to Poppendieck’s Principles of Lean Thinking - &quot;The effect of ‘pull’ is that production is not based on forecast; commitment is delayed until demand is present to indicate what the customer really wants.&quot;  The bottom line is that with either process, adding value according to the customer’s needs will be the focus of development. If there is a drastic change in “value” that renders previous work as waste, then there are probably bigger issues.</description>
		<content:encoded><![CDATA[<p>Thanks for the clarification.  I am still working with these concepts at a theoretical level.  My current work has us locked into a very ordered development process (Waterfall), which in the past has worked well for our customer and the types of products we are developing.  The part that kills our current schedules is obviously change, especially in requirements.  I am more familiar with the Agile/Scrum methodology then Lean.  My point above stems from the fact that Lean strives to reduce waste, but couldn’t waste occur in requirement change with  overproduction, extra processing, and waiting? </p>
<p>I definitely see how the two processes are similar and I can see how the concept of “pull” relates to the Agile principles.  Not to beat a dead horse, but isn’t the Lean Practitioner’s view of pull different from the Agile Practitioner’s principle of “welcoming change” late in the development process?   According to Poppendieck’s Principles of Lean Thinking &#8211; &#8220;The effect of ‘pull’ is that production is not based on forecast; commitment is delayed until demand is present to indicate what the customer really wants.&#8221;  The bottom line is that with either process, adding value according to the customer’s needs will be the focus of development. If there is a drastic change in “value” that renders previous work as waste, then there are probably bigger issues.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Siddharta</title>
		<link>http://www.rallydev.com/agileblog/2009/06/agile-and-lean-software-development-an-oxymoron/#comment-3513</link>
		<dc:creator>Siddharta</dc:creator>
		<pubDate>Tue, 23 Jun 2009 12:11:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.rallydev.com/agileblog/?p=2427#comment-3513</guid>
		<description>Scott, in a kanban pull process, the backlog can change upto the last moment before the work has started on an item. In that sense I would say that a lean process welcomes change in requirements even more than Scrum.

I would support Kent&#039;s view here. The key principle in agile is acting on customer feedback, whereas lean is more about streamlining the flow. I don&#039;t see why both cannot go hand in hand.</description>
		<content:encoded><![CDATA[<p>Scott, in a kanban pull process, the backlog can change upto the last moment before the work has started on an item. In that sense I would say that a lean process welcomes change in requirements even more than Scrum.</p>
<p>I would support Kent&#8217;s view here. The key principle in agile is acting on customer feedback, whereas lean is more about streamlining the flow. I don&#8217;t see why both cannot go hand in hand.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
