<?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: Scrum mania</title>
	<atom:link href="http://www.GeekMBA360.com/scrum-mania/feed" rel="self" type="application/rss+xml" />
	<link>http://www.GeekMBA360.com/scrum-mania</link>
	<description>Career Advice At The Intersection Of Business And Technology</description>
	<lastBuildDate>Mon, 06 Sep 2010 00:11:02 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Ted Howard</title>
		<link>http://www.GeekMBA360.com/scrum-mania/comment-page-1#comment-243</link>
		<dc:creator>Ted Howard</dc:creator>
		<pubDate>Tue, 02 Dec 2008 21:55:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.GeekMBA360.com/?p=393#comment-243</guid>
		<description>I&#039;ve worked on a team that ran scrums of one month. As planning began, we usually knew what our customers would ask us to do but sometimes we had a surprise and change of our expectations. We would set the plan, sprint to the final demo, show off, and repeat. It was smooth.

I&#039;ve also worked on a team building a product that took 6+ months to build. They used scrum. Well, really they had a traditional development process and masqueraded as scrum by having a monthly milestone and progress meeting with management. Every sprint&#039;s tasks were basically decided months beforehand, so it wasn&#039;t scrum in that sense. The product was never ready to release until that final sprint, so it was scrum in that sense either.

I think it was a better way to run a standard development cycle just because management knew what was going on, demos forced periodic quality checks, and demos also provided morale boosts. If we had to mis-use the term &#039;scrum&#039; then I think it was a fair price to pay.

The way I&#039;ve seen scrum go awry is when it becomes process for the sake of process. It sounds like you witnessed training for the sake of process for the sake of process. Read Paul Graham&#039;s latest:
http://www.paulgraham.com/artistsship.html

Ted</description>
		<content:encoded><![CDATA[<p>I&#8217;ve worked on a team that ran scrums of one month. As planning began, we usually knew what our customers would ask us to do but sometimes we had a surprise and change of our expectations. We would set the plan, sprint to the final demo, show off, and repeat. It was smooth.</p>
<p>I&#8217;ve also worked on a team building a product that took 6+ months to build. They used scrum. Well, really they had a traditional development process and masqueraded as scrum by having a monthly milestone and progress meeting with management. Every sprint&#8217;s tasks were basically decided months beforehand, so it wasn&#8217;t scrum in that sense. The product was never ready to release until that final sprint, so it was scrum in that sense either.</p>
<p>I think it was a better way to run a standard development cycle just because management knew what was going on, demos forced periodic quality checks, and demos also provided morale boosts. If we had to mis-use the term &#8217;scrum&#8217; then I think it was a fair price to pay.</p>
<p>The way I&#8217;ve seen scrum go awry is when it becomes process for the sake of process. It sounds like you witnessed training for the sake of process for the sake of process. Read Paul Graham&#8217;s latest:<br />
<a href="http://www.paulgraham.com/artistsship.html" rel="nofollow">http://www.paulgraham.com/artistsship.html</a></p>
<p>Ted</p>
]]></content:encoded>
	</item>
</channel>
</rss>
