<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	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:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Irie, Inc. &#187; scrum</title>
	<atom:link href="http://www.irie-inc.com/tag/scrum/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.irie-inc.com</link>
	<description>Agile Software Development Consulting</description>
	<lastBuildDate>Mon, 02 May 2011 19:51:36 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.2</generator>
		<item>
		<title>The Agile Manifesto</title>
		<link>http://www.irie-inc.com/2009/10/25/the-agile-manifesto/</link>
		<comments>http://www.irie-inc.com/2009/10/25/the-agile-manifesto/#comments</comments>
		<pubDate>Sun, 25 Oct 2009 21:32:30 +0000</pubDate>
		<dc:creator>jarrowwx</dc:creator>
				<category><![CDATA[Agile Training]]></category>
		<category><![CDATA[agile manifesto]]></category>
		<category><![CDATA[agile software development]]></category>
		<category><![CDATA[burndown]]></category>
		<category><![CDATA[change]]></category>
		<category><![CDATA[collaboration]]></category>
		<category><![CDATA[communication]]></category>
		<category><![CDATA[contracts]]></category>
		<category><![CDATA[documentation]]></category>
		<category><![CDATA[process]]></category>
		<category><![CDATA[scrum]]></category>
		<category><![CDATA[tools]]></category>
		<category><![CDATA[working software]]></category>

		<guid isPermaLink="false">http://www.irie-inc.com/?p=11</guid>
		<description><![CDATA[Uncovering better ways of developing software, and helping others do it, too.]]></description>
			<content:encoded><![CDATA[<blockquote>
<p>We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:</p>
<p>
<b>Individuals and interactions</b> over processes and tools<br />
<b>Working software</b> over comprehensive documentation<br />
<b>Customer collaboration</b> over contract negotiation<br />
<b>Responding to change</b> over following a plan
</p>
<p>That is, while there is value in the items on the right, we value the items on the left more.</p>
</blockquote>
<p><b>Individuals and interactions over processes and tools</b></p>
<p>
Burndown charts are tools.  Obviously, they are valuable.  But they are only valuable insofar as they help individuals engage one another.  A burndown chart reveals where the team is compared to what they committed to.  It reveals whether the team over-committed or over-estimated.  But ultimately, it is a tool to encourage communication.  It is a signal when things are wrong, or when there are opportunities for positive change.  But the tool has no value if no one is looking at it.  It has no value if no one knows how to interpret it.  The tool has value only as a means to an end, that end being the constructive dialogue of the team, and the continuous improvement of the process.
</p>
<p>
Scrum is a framework, a &#8216;process&#8217;. It is the most popular implementation of Agile software development.  Obviously, it is valuable.  But what gives it that value?  The dialogue between the team members that happens on a daily basis.  The dialog that happens between the team and the customer on a regular basis.  The way in which it reveals shortcomings in the way the team or the company works.  But all of the trappings of Scrum are of none effect if they do not lead to continuous discussion and improvement.  Again, the process serves to highlight the need for communication, and creates a context for it to take place.  But having the trappings of Scrum without the dialogue and the evolution of the team that it facilitates, and you get very little from it.
</p>
<p><b>Working software over comprehensive documentation</b></p>
<p>Documentation is valuable as a tool for communication.  Its purpose is to help everyone get on the same page.  Of course, having everybody together in the same room, having a lively discussion, getting all of the details out, all this yields the same results, in a fraction of the time, and with significantly higher value.  The other value of documentation is to convey information to those that could not be there for that meeting.  Of course, being able to point to what was built and say &#8220;That&#8217;s what we built&#8221; is just as good as pointing to a document and saying &#8220;that tells you about what we built&#8221;, in most cases.  That&#8217;s not to say that documentation has no place.  If it is hard to wrap your brain around it, document it, save someone else from having to spend as much time doing so.  But if it is self-evident, documenting it is a case of putting the process before the results the process is intended to achieve.  Like mindlessly serving a tyrant king.
</p>
<p>
Besides, at the end of the day, customers don&#8217;t use your process documentation.  They use the working software.  If you have to stop half way through the project, and all you have is documentation, you have nothing of value.
</p>
<p><b>Customer collaboration over contract negotiation</b> </p>
<p>
&#8220;That&#8217;s not what you asked for!&#8221; &#8220;But that&#8217;s what I <i>need</i>!&#8221;  Contracts are important because they set expectations, and they define roles.  But they can also serve as a pair of handcuffs.  The customer doesn&#8217;t win when they can&#8217;t get what they want because they didn&#8217;t ask for it up front.  And the team doesn&#8217;t win when the customer is dissatisfied.  In a customer service organization, which ultimately every development organization ultimately is, your success and longevity is determined by how well you can serve the needs of the customer.  The contracts that you negotiate should help you do that, not hinder it.
</p>
<p><b>Responding to change over following a plan</b></p>
<p>
Plans are essential.  Even in Agile development, you need to plan your work and work your plan.  But circumstances change.  The plan needs to change, too.  It&#8217;s a lot of work to create a plan that lays out the next 2 years.  Having to go back to the drawing board after six weeks is demoralizing, and a huge waste of effort.  Refusing to go back to the drawing board, even though you should, will ruin you.  The further out in time you plan, the less detailed your plans should be, so that effort is not wasted as you adapt to the inevitable changes that come your way.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.irie-inc.com/2009/10/25/the-agile-manifesto/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

