<?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: Quality of Life? Does it Exist?</title>
	<atom:link href="http://blog.franktrindade.com/2008/04/23/quality-of-life-does-it-exist/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.franktrindade.com/2008/04/23/quality-of-life-does-it-exist/</link>
	<description>Agile, software and some non-sense</description>
	<lastBuildDate>Thu, 17 Jun 2010 09:41:19 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
	<item>
		<title>By: franktrindade</title>
		<link>http://blog.franktrindade.com/2008/04/23/quality-of-life-does-it-exist/comment-page-1/#comment-29</link>
		<dc:creator>franktrindade</dc:creator>
		<pubDate>Tue, 13 May 2008 20:40:10 +0000</pubDate>
		<guid isPermaLink="false">http://franktrindade.wordpress.com/?p=38#comment-29</guid>
		<description>Charles,

interesting comment. Maybe you can get some clues going back to the InfoQ article and reading the information provided by the same person when asked  &quot;What&#039;s the biggest problem during the adoption, and how did you solve it?&quot;

And the answers were:

First of all, we needed to get the boss to support us. And then, to tell the truth, adopting Scrum is pretty easy, much easier than CMMI.

The most difficult thing is that you need to resolve the problems revealed in the process, such as:

   1. &quot;We don&#039;t have clear requirements, resulting in a high cost of communication in late stages. We spend too much time discussing with the product manager again and again.&quot;
   2. &quot;Delivery cycle is too long: our Sprint is 3 or 4 weeks long, but the product manager hopes we can deliver two versions per week.&quot;
   3. &quot;We cannot master the historical requirement and the product architecture based on the Scrum characteristics.&quot;
   4. &quot;The delivery date is fixed by the business guys, so we don&#039;t have time to do unit tests, nor code reviews.&quot;
   5. &quot;We cannot clearly see the bottlenecks between tasks, or how to coordinate everyone.&quot;
   6. &quot;We need at least one week for analysing the data after deployment, it&#039;s impossible to conclude how to make improvement right after the current sprint.&quot;
   7. &quot;The pace of development is too fast, we don&#039;t have enough time to stop and do a good retrospective. The historical requirement isn&#039;t fully used.&quot;</description>
		<content:encoded><![CDATA[<p>Charles,</p>
<p>interesting comment. Maybe you can get some clues going back to the InfoQ article and reading the information provided by the same person when asked  &#8220;What&#8217;s the biggest problem during the adoption, and how did you solve it?&#8221;</p>
<p>And the answers were:</p>
<p>First of all, we needed to get the boss to support us. And then, to tell the truth, adopting Scrum is pretty easy, much easier than CMMI.</p>
<p>The most difficult thing is that you need to resolve the problems revealed in the process, such as:</p>
<p>   1. &#8220;We don&#8217;t have clear requirements, resulting in a high cost of communication in late stages. We spend too much time discussing with the product manager again and again.&#8221;<br />
   2. &#8220;Delivery cycle is too long: our Sprint is 3 or 4 weeks long, but the product manager hopes we can deliver two versions per week.&#8221;<br />
   3. &#8220;We cannot master the historical requirement and the product architecture based on the Scrum characteristics.&#8221;<br />
   4. &#8220;The delivery date is fixed by the business guys, so we don&#8217;t have time to do unit tests, nor code reviews.&#8221;<br />
   5. &#8220;We cannot clearly see the bottlenecks between tasks, or how to coordinate everyone.&#8221;<br />
   6. &#8220;We need at least one week for analysing the data after deployment, it&#8217;s impossible to conclude how to make improvement right after the current sprint.&#8221;<br />
   7. &#8220;The pace of development is too fast, we don&#8217;t have enough time to stop and do a good retrospective. The historical requirement isn&#8217;t fully used.&#8221;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Boris Gloger</title>
		<link>http://blog.franktrindade.com/2008/04/23/quality-of-life-does-it-exist/comment-page-1/#comment-27</link>
		<dc:creator>Boris Gloger</dc:creator>
		<pubDate>Fri, 25 Apr 2008 22:04:10 +0000</pubDate>
		<guid isPermaLink="false">http://franktrindade.wordpress.com/?p=38#comment-27</guid>
		<description>I completely agree. Scrum shall make fun. The one and most important aspect of doing Scrum form me was and is have a more fun, and more happiness in work.
I do coaching and training since 2004 and one thing is absolutely common in all successful implementations of Scrum, who did Scrum do want to do nothing else anymore.</description>
		<content:encoded><![CDATA[<p>I completely agree. Scrum shall make fun. The one and most important aspect of doing Scrum form me was and is have a more fun, and more happiness in work.<br />
I do coaching and training since 2004 and one thing is absolutely common in all successful implementations of Scrum, who did Scrum do want to do nothing else anymore.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Charles</title>
		<link>http://blog.franktrindade.com/2008/04/23/quality-of-life-does-it-exist/comment-page-1/#comment-28</link>
		<dc:creator>Charles</dc:creator>
		<pubDate>Thu, 24 Apr 2008 15:24:05 +0000</pubDate>
		<guid isPermaLink="false">http://franktrindade.wordpress.com/?p=38#comment-28</guid>
		<description>Of particular interest is the roughly 1/3 of developers that classified Scrum as &#039;worse&#039; or &#039;much worse&#039; than their previous approach. In my own experience, this ratio seems to hold true for Agile practices in general and not Scrum specifically... in other words, there seems to be a non-trivial percentage of developers that reject the Agile experience.

And so, we are now presented with an opportunity to advance the state of the art by investigating and better understanding the individuals and organizations that reject Agile adoption, and the nature of those failures. Is it a marketing problem? An organizational effectiveness issue? Or perhaps something more emotional or psychological in nature?

Any readers with experience with this problem?</description>
		<content:encoded><![CDATA[<p>Of particular interest is the roughly 1/3 of developers that classified Scrum as &#8216;worse&#8217; or &#8216;much worse&#8217; than their previous approach. In my own experience, this ratio seems to hold true for Agile practices in general and not Scrum specifically&#8230; in other words, there seems to be a non-trivial percentage of developers that reject the Agile experience.</p>
<p>And so, we are now presented with an opportunity to advance the state of the art by investigating and better understanding the individuals and organizations that reject Agile adoption, and the nature of those failures. Is it a marketing problem? An organizational effectiveness issue? Or perhaps something more emotional or psychological in nature?</p>
<p>Any readers with experience with this problem?</p>
]]></content:encoded>
	</item>
</channel>
</rss>
