<?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/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: Scrum Will Die</title>
	<atom:link href="http://simpleprogrammer.com/2010/02/23/scrum-will-die/feed/" rel="self" type="application/rss+xml" />
	<link>http://simpleprogrammer.com/2010/02/23/scrum-will-die/</link>
	<description>Software Development from John Sonmez&#039;s Perspective</description>
	<lastBuildDate>Thu, 17 May 2012 13:16:12 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Harsha</title>
		<link>http://simpleprogrammer.com/2010/02/23/scrum-will-die/#comment-2545</link>
		<dc:creator><![CDATA[Harsha]]></dc:creator>
		<pubDate>Tue, 01 May 2012 19:10:44 +0000</pubDate>
		<guid isPermaLink="false">http://simpleprogrammer.com/?p=409#comment-2545</guid>
		<description><![CDATA[Great discussions (and perceptions, perhaps!) Here is mine. 
My understanding of Scrum is that it is a project delivery methodology (okay, let me suppose we are in the context of software, so lets say software delivery methodology, though It was evolved at somewhere) rather than software &quot;development&quot; methodology. Software development has to be done in its own phases (requirement gathering to deployment) and not any other way. [I dont think we like to switch our focus of discussion to the phases of software development and their need]. Scrum sits over the SDLC as a delivery model. I think ALL that scrum talks of is the &quot;delivery&quot; model. Waterfall and like models focused mainly on the technical aspects of the project rather than &quot;project management and delivery&quot; and I think scrum is doing exactly the opposite, emphasizing ONLY on the &quot;delivery&quot; and never ever talks explicitly about the things that complements scrum. This is where the &quot;assumptions and customizations bud&quot;. Waterfall model did have an inherent delivery model. 
I am not against scrum, It is good if everyone follows and to the letter.
As discussed by the author of this blog and many others who agree (or at least understand), Scrum is not a silver bullet. And scrum is not everything. Scrum is no different from iterative and incremental model. It does not state the change in the phases of development. But some &quot;wasted time&quot; is removed indirectly by being different in the fact that the shorter release cycles, regular communication, stake holders involvement is increased so the business &quot;RISKS&quot; are identified earlier etc etc. Scrum does SDLC inherently and underestimates technical aspects of it like the waterfall like models did for delivery. Scrum might die as per some of our understanding, or will evolve. We can&#039;t predict the future but know the direction.

Scrum has benefits: faster delivery, evolved design artifacts, etc. 
Scrum says follow simple process(es) and relies on &quot;release early and release often principle which is good. It also says Don&#039;t do anything that is not needed, may be design or a feature or detailed documentation when it is not used by anyone else; this is fantastic

My concern here is Scrum should not be an excuse. We should be using complementing tools/processes. And make the teams following Scrum aware of the fact that it is a delivery model and not a development model. Some other points are already discussed above by others in this post.]]></description>
		<content:encoded><![CDATA[<p>Great discussions (and perceptions, perhaps!) Here is mine.<br />
My understanding of Scrum is that it is a project delivery methodology (okay, let me suppose we are in the context of software, so lets say software delivery methodology, though It was evolved at somewhere) rather than software &#8220;development&#8221; methodology. Software development has to be done in its own phases (requirement gathering to deployment) and not any other way. [I dont think we like to switch our focus of discussion to the phases of software development and their need]. Scrum sits over the SDLC as a delivery model. I think ALL that scrum talks of is the &#8220;delivery&#8221; model. Waterfall and like models focused mainly on the technical aspects of the project rather than &#8220;project management and delivery&#8221; and I think scrum is doing exactly the opposite, emphasizing ONLY on the &#8220;delivery&#8221; and never ever talks explicitly about the things that complements scrum. This is where the &#8220;assumptions and customizations bud&#8221;. Waterfall model did have an inherent delivery model.<br />
I am not against scrum, It is good if everyone follows and to the letter.<br />
As discussed by the author of this blog and many others who agree (or at least understand), Scrum is not a silver bullet. And scrum is not everything. Scrum is no different from iterative and incremental model. It does not state the change in the phases of development. But some &#8220;wasted time&#8221; is removed indirectly by being different in the fact that the shorter release cycles, regular communication, stake holders involvement is increased so the business &#8220;RISKS&#8221; are identified earlier etc etc. Scrum does SDLC inherently and underestimates technical aspects of it like the waterfall like models did for delivery. Scrum might die as per some of our understanding, or will evolve. We can&#8217;t predict the future but know the direction.</p>
<p>Scrum has benefits: faster delivery, evolved design artifacts, etc.<br />
Scrum says follow simple process(es) and relies on &#8220;release early and release often principle which is good. It also says Don&#8217;t do anything that is not needed, may be design or a feature or detailed documentation when it is not used by anyone else; this is fantastic</p>
<p>My concern here is Scrum should not be an excuse. We should be using complementing tools/processes. And make the teams following Scrum aware of the fact that it is a delivery model and not a development model. Some other points are already discussed above by others in this post.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Sebastian</title>
		<link>http://simpleprogrammer.com/2010/02/23/scrum-will-die/#comment-2499</link>
		<dc:creator><![CDATA[Sebastian]]></dc:creator>
		<pubDate>Sat, 31 Mar 2012 09:52:31 +0000</pubDate>
		<guid isPermaLink="false">http://simpleprogrammer.com/?p=409#comment-2499</guid>
		<description><![CDATA[I can relate 100% to what you are writing here.

We are experiencing exactly the same problems at my company. Much might have to do with the company culture (or lack thereof). But I have the constant feeling that we are fighting to &quot;conform&quot; to Scrum, rather that it helping us be more productive.

Thanks for the post.]]></description>
		<content:encoded><![CDATA[<p>I can relate 100% to what you are writing here.</p>
<p>We are experiencing exactly the same problems at my company. Much might have to do with the company culture (or lack thereof). But I have the constant feeling that we are fighting to &#8220;conform&#8221; to Scrum, rather that it helping us be more productive.</p>
<p>Thanks for the post.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Advocate</title>
		<link>http://simpleprogrammer.com/2010/02/23/scrum-will-die/#comment-2222</link>
		<dc:creator><![CDATA[Advocate]]></dc:creator>
		<pubDate>Tue, 22 Nov 2011 05:23:52 +0000</pubDate>
		<guid isPermaLink="false">http://simpleprogrammer.com/?p=409#comment-2222</guid>
		<description><![CDATA[Checkout Delusional Scrum - http://lifeelement.com/news/delusional-scrum/]]></description>
		<content:encoded><![CDATA[<p>Checkout Delusional Scrum &#8211; <a href="http://lifeelement.com/news/delusional-scrum/" rel="nofollow">http://lifeelement.com/news/delusional-scrum/</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jsonmez</title>
		<link>http://simpleprogrammer.com/2010/02/23/scrum-will-die/#comment-2183</link>
		<dc:creator><![CDATA[jsonmez]]></dc:creator>
		<pubDate>Thu, 20 Oct 2011 01:41:56 +0000</pubDate>
		<guid isPermaLink="false">http://simpleprogrammer.com/?p=409#comment-2183</guid>
		<description><![CDATA[That is pretty awesome!]]></description>
		<content:encoded><![CDATA[<p>That is pretty awesome!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Quincy</title>
		<link>http://simpleprogrammer.com/2010/02/23/scrum-will-die/#comment-2182</link>
		<dc:creator><![CDATA[John Quincy]]></dc:creator>
		<pubDate>Thu, 20 Oct 2011 01:36:47 +0000</pubDate>
		<guid isPermaLink="false">http://simpleprogrammer.com/?p=409#comment-2182</guid>
		<description><![CDATA[You are so right!!!
You might get a kick out of this video:

http://www.youtube.com/watch?v=nvks70PD0Rs

John]]></description>
		<content:encoded><![CDATA[<p>You are so right!!!<br />
You might get a kick out of this video:</p>
<p><span style="text-align:center; display: block;"><a href="http://simpleprogrammer.com/2010/02/23/scrum-will-die/"><img src="http://img.youtube.com/vi/nvks70PD0Rs/2.jpg" alt="" /></a></span></p>
<p>John</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: A Drawback of Agile &#171; Making the Complex Simple</title>
		<link>http://simpleprogrammer.com/2010/02/23/scrum-will-die/#comment-1985</link>
		<dc:creator><![CDATA[A Drawback of Agile &#171; Making the Complex Simple]]></dc:creator>
		<pubDate>Sun, 03 Jul 2011 22:26:30 +0000</pubDate>
		<guid isPermaLink="false">http://simpleprogrammer.com/?p=409#comment-1985</guid>
		<description><![CDATA[[...] have written in the past about some of the shortcomings of specific agile methodologies.&#160; I’ve even suggested a new one [...]]]></description>
		<content:encoded><![CDATA[<p>[...] have written in the past about some of the shortcomings of specific agile methodologies.&#160; I’ve even suggested a new one [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jsonmez</title>
		<link>http://simpleprogrammer.com/2010/02/23/scrum-will-die/#comment-1297</link>
		<dc:creator><![CDATA[jsonmez]]></dc:creator>
		<pubDate>Mon, 15 Nov 2010 15:53:15 +0000</pubDate>
		<guid isPermaLink="false">http://simpleprogrammer.com/?p=409#comment-1297</guid>
		<description><![CDATA[I agree with you.]]></description>
		<content:encoded><![CDATA[<p>I agree with you.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: kirschilan</title>
		<link>http://simpleprogrammer.com/2010/02/23/scrum-will-die/#comment-1296</link>
		<dc:creator><![CDATA[kirschilan]]></dc:creator>
		<pubDate>Mon, 15 Nov 2010 15:46:34 +0000</pubDate>
		<guid isPermaLink="false">http://simpleprogrammer.com/?p=409#comment-1296</guid>
		<description><![CDATA[I like your post. Not that I agree with most of it - In fact, I disagree with quite a lot of what you&#039;ve said.
But I do agree with the bottom line (or the title, in this case)  : SCRUM will die.
However, it is not the death of Waterfall and other rigid or artefact-driven methodologies. These will die because they put little focus on people and a lot of focus on technical deliverables.

SCRUM will die and make way for an evolved framework, one that takes the agile values combined with the practicality and quick-start-liness of SCRUM, compared to other agile frameworks; Be it SCRUM-Ban or something else.

Note, that JIT, aka TPS, aka Toyota Production System, evolved between 1948 and 1975. It took 30 odd years for it to become what it is today, and its principles and values are being adopted in various other frameworks.

As you suggest in your piece, SCRUM per-se might die, but it will evolve into other agile software development frameworks. 
Waterfall and the likes, however, are doomed to decline and ultimately disappear, much to the delight of enlightened business and technical people alike.]]></description>
		<content:encoded><![CDATA[<p>I like your post. Not that I agree with most of it &#8211; In fact, I disagree with quite a lot of what you&#8217;ve said.<br />
But I do agree with the bottom line (or the title, in this case)  : SCRUM will die.<br />
However, it is not the death of Waterfall and other rigid or artefact-driven methodologies. These will die because they put little focus on people and a lot of focus on technical deliverables.</p>
<p>SCRUM will die and make way for an evolved framework, one that takes the agile values combined with the practicality and quick-start-liness of SCRUM, compared to other agile frameworks; Be it SCRUM-Ban or something else.</p>
<p>Note, that JIT, aka TPS, aka Toyota Production System, evolved between 1948 and 1975. It took 30 odd years for it to become what it is today, and its principles and values are being adopted in various other frameworks.</p>
<p>As you suggest in your piece, SCRUM per-se might die, but it will evolve into other agile software development frameworks.<br />
Waterfall and the likes, however, are doomed to decline and ultimately disappear, much to the delight of enlightened business and technical people alike.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: When Scrum Hurts: Mob Achitecture &#171; Making the Complex Simple</title>
		<link>http://simpleprogrammer.com/2010/02/23/scrum-will-die/#comment-283</link>
		<dc:creator><![CDATA[When Scrum Hurts: Mob Achitecture &#171; Making the Complex Simple]]></dc:creator>
		<pubDate>Fri, 12 Mar 2010 19:08:12 +0000</pubDate>
		<guid isPermaLink="false">http://simpleprogrammer.com/?p=409#comment-283</guid>
		<description><![CDATA[[...] Hurts: Mob&#160;Achitecture    If you have been following my blog, you know that I have a love/hate relationship with [...]]]></description>
		<content:encoded><![CDATA[<p>[...] Hurts: Mob&nbsp;Achitecture    If you have been following my blog, you know that I have a love/hate relationship with [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Urs Enzler</title>
		<link>http://simpleprogrammer.com/2010/02/23/scrum-will-die/#comment-255</link>
		<dc:creator><![CDATA[Urs Enzler]]></dc:creator>
		<pubDate>Tue, 02 Mar 2010 07:28:54 +0000</pubDate>
		<guid isPermaLink="false">http://simpleprogrammer.com/?p=409#comment-255</guid>
		<description><![CDATA[I totally agree that most teams claiming doing Scrum, don&#039;t do it at all.
But this is not the problem of the process.

Furthermore, Scrum is called a framework because you have to adapt it to your needs, there is no way around this. If you get no value out of defining tasks, then don&#039;t do it. Maybe try spiking first and then define tasks.
I agree with you that Scrum is not best for maintaining software. Kanban may be a better choice for this activity.

I just want to say that switching to another agile process without getting rid of the root problems won&#039;t help much. If you (or probably more your management) don&#039;t have an agile mindset, then all these methodologies will sooner or later hit a wall.

Very interesting discussions here - thanks
Urs]]></description>
		<content:encoded><![CDATA[<p>I totally agree that most teams claiming doing Scrum, don&#8217;t do it at all.<br />
But this is not the problem of the process.</p>
<p>Furthermore, Scrum is called a framework because you have to adapt it to your needs, there is no way around this. If you get no value out of defining tasks, then don&#8217;t do it. Maybe try spiking first and then define tasks.<br />
I agree with you that Scrum is not best for maintaining software. Kanban may be a better choice for this activity.</p>
<p>I just want to say that switching to another agile process without getting rid of the root problems won&#8217;t help much. If you (or probably more your management) don&#8217;t have an agile mindset, then all these methodologies will sooner or later hit a wall.</p>
<p>Very interesting discussions here &#8211; thanks<br />
Urs</p>
]]></content:encoded>
	</item>
</channel>
</rss>

