<?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 Software Development - Road Trip Analogy</title>
	<atom:link href="http://www.pmhut.com/agile-software-development-road-trip-analogy/feed" rel="self" type="application/rss+xml" />
	<link>http://www.pmhut.com/agile-software-development-road-trip-analogy</link>
	<description></description>
	<pubDate>Sat, 11 Feb 2012 23:59:46 +0000</pubDate>
	<generator>http://wordpress.org/?v=abc</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: John Tailby</title>
		<link>http://www.pmhut.com/agile-software-development-road-trip-analogy/comment-page-1#comment-18255</link>
		<dc:creator>John Tailby</dc:creator>
		<pubDate>Thu, 04 Mar 2010 02:14:03 +0000</pubDate>
		<guid isPermaLink="false">http://www.pmhut.com/?p=4877#comment-18255</guid>
		<description>Hi Keith

What you said does make sense, especially the part about management not knowing or accepting that different styles of management are needed for different styles of work.

To me your story underpins how far away from being ready for agile style development many of our corporations and government agencies are and how much they would have to reinvent themselves before they could participate in an agile style project.

I was simply trying to imagine applying what you wrote onto the project landscape of customer organisations that I know about. Trying to do agile in the existing climate would be quite rocky.</description>
		<content:encoded><![CDATA[<p>Hi Keith</p>
<p>What you said does make sense, especially the part about management not knowing or accepting that different styles of management are needed for different styles of work.</p>
<p>To me your story underpins how far away from being ready for agile style development many of our corporations and government agencies are and how much they would have to reinvent themselves before they could participate in an agile style project.</p>
<p>I was simply trying to imagine applying what you wrote onto the project landscape of customer organisations that I know about. Trying to do agile in the existing climate would be quite rocky.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Keith Swenson</title>
		<link>http://www.pmhut.com/agile-software-development-road-trip-analogy/comment-page-1#comment-18109</link>
		<dc:creator>Keith Swenson</dc:creator>
		<pubDate>Mon, 01 Mar 2010 23:51:11 +0000</pubDate>
		<guid isPermaLink="false">http://www.pmhut.com/?p=4877#comment-18109</guid>
		<description>There is no question that micro management is rampant, and in some cases entirely inescapable.  What you mention is indeed a common corporate culture.

I wrote this piece as a way to try to explain that not all work is manageable through these means.  There are different kinds of work.  When building a bridge, you have a very predictable process, where each step can be mapped out in detail in advance.  But there are other kinds of work that are inherently unpredictable.  The exploration is a visual example of this.  No doubt Ferdinand and Isabella WANTED a precise detailed day-by-day plan from Christopher Columbus, but the nature of exploration made that impossible -- and they knew this.

This story is not to say that all projects should be left without any management control, but that there are some kinds of projects which simply can not be controlled this way.  All too often management does NOT know this.  Software development is a voyage of discovery into uncharted territory.  So treatment of unusual diseases.  So is coming up with a new product idea.  So is writing a hit song.  So is finding the criminal behind a robbery or murder.  So is negotiating a treaty.  These types of work are not predictable, and so can not be managed by scientific management, which assumes that such things are predictable.

Also, you should not mistake "plan" for "goal".  It is necessarily the case that those people funding a project will want to be very clear about the goal of the project.  Nobody is saying they want multi-millions to spend on whatever they want.  Even Columbus had a clear goal: sail to the new world.  And his backers can measure success or failure against that goal.  But, what this analogy argues for, is that every single step, every detailed daily plan, is NOT knowable in advance, and that it is figured out by heuristics that will be applied at the time that the work is performed.  

It is also true that these needs to be constant engagement.  If Columbus could have telephoned home to report position and progress, that would have been perfect.  You MUST interact regularly and continuously with the customer saying "I am 'here', and I see X, Y, and Z, and what do you think about heading toward 'there'".  This is not saying that you are going off wild with the money, but instead simply that the exact plan to reach the goal can not be stated in detail ahead of time.  Make sense?

Here is a link to more discussion of this article:

http://kswenson.wordpress.com/2008/09/02/agile-development-road-trip-analogy/</description>
		<content:encoded><![CDATA[<p>There is no question that micro management is rampant, and in some cases entirely inescapable.  What you mention is indeed a common corporate culture.</p>
<p>I wrote this piece as a way to try to explain that not all work is manageable through these means.  There are different kinds of work.  When building a bridge, you have a very predictable process, where each step can be mapped out in detail in advance.  But there are other kinds of work that are inherently unpredictable.  The exploration is a visual example of this.  No doubt Ferdinand and Isabella WANTED a precise detailed day-by-day plan from Christopher Columbus, but the nature of exploration made that impossible &#8212; and they knew this.</p>
<p>This story is not to say that all projects should be left without any management control, but that there are some kinds of projects which simply can not be controlled this way.  All too often management does NOT know this.  Software development is a voyage of discovery into uncharted territory.  So treatment of unusual diseases.  So is coming up with a new product idea.  So is writing a hit song.  So is finding the criminal behind a robbery or murder.  So is negotiating a treaty.  These types of work are not predictable, and so can not be managed by scientific management, which assumes that such things are predictable.</p>
<p>Also, you should not mistake &#8220;plan&#8221; for &#8220;goal&#8221;.  It is necessarily the case that those people funding a project will want to be very clear about the goal of the project.  Nobody is saying they want multi-millions to spend on whatever they want.  Even Columbus had a clear goal: sail to the new world.  And his backers can measure success or failure against that goal.  But, what this analogy argues for, is that every single step, every detailed daily plan, is NOT knowable in advance, and that it is figured out by heuristics that will be applied at the time that the work is performed.  </p>
<p>It is also true that these needs to be constant engagement.  If Columbus could have telephoned home to report position and progress, that would have been perfect.  You MUST interact regularly and continuously with the customer saying &#8220;I am &#8216;here&#8217;, and I see X, Y, and Z, and what do you think about heading toward &#8216;there&#8217;&#8221;.  This is not saying that you are going off wild with the money, but instead simply that the exact plan to reach the goal can not be stated in detail ahead of time.  Make sense?</p>
<p>Here is a link to more discussion of this article:</p>
<p><a href="http://kswenson.wordpress.com/2008/09/02/agile-development-road-trip-analogy/" rel="nofollow">http://kswenson.wordpress.com/2008/09/02/agile-development-road-trip-analogy/</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Tailby</title>
		<link>http://www.pmhut.com/agile-software-development-road-trip-analogy/comment-page-1#comment-18035</link>
		<dc:creator>John Tailby</dc:creator>
		<pubDate>Sun, 28 Feb 2010 20:44:21 +0000</pubDate>
		<guid isPermaLink="false">http://www.pmhut.com/?p=4877#comment-18035</guid>
		<description>How does this approach work in a corporate environment?
Most large corporations or government agencies have very restrictive approaches to project delivery.

They won't let you jump in a car with a tank full of money and a vague note saying you may be back with dinner but don't know if it will be fish, beef, chicken or vegetarian.

Most large organisations have teams of people that are the stakeholders who all want a say in where the project is going, and many have departments who want a say in solution design. In these sorts of organisations it would be like having 20 people telling you where to go and another team of people telling you that you were not driving in accordance with corporate policy.

I don't think you can do an agile project without a lot of work being done within the customer organisation to make it ready to engage in an agile way.

The organisation has to give the decision making power to one person to define the requirements. They also have to allow the project team to refactor the solution when the requirements change or were incorrectly interpreted in a sprint. What project team would currently get away with reporting to the steering committee that they need to go back and refactor or redo last months sprint and can you have some more money?</description>
		<content:encoded><![CDATA[<p>How does this approach work in a corporate environment?<br />
Most large corporations or government agencies have very restrictive approaches to project delivery.</p>
<p>They won&#8217;t let you jump in a car with a tank full of money and a vague note saying you may be back with dinner but don&#8217;t know if it will be fish, beef, chicken or vegetarian.</p>
<p>Most large organisations have teams of people that are the stakeholders who all want a say in where the project is going, and many have departments who want a say in solution design. In these sorts of organisations it would be like having 20 people telling you where to go and another team of people telling you that you were not driving in accordance with corporate policy.</p>
<p>I don&#8217;t think you can do an agile project without a lot of work being done within the customer organisation to make it ready to engage in an agile way.</p>
<p>The organisation has to give the decision making power to one person to define the requirements. They also have to allow the project team to refactor the solution when the requirements change or were incorrectly interpreted in a sprint. What project team would currently get away with reporting to the steering committee that they need to go back and refactor or redo last months sprint and can you have some more money?</p>
]]></content:encoded>
	</item>
</channel>
</rss>

