<?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: Study notes &#8211; &#8220;Lean Software Development&#8221; Chapter 1</title>
	<atom:link href="http://www.synesthesia.co.uk/blog/archives/2003/10/06/study-notes-lean-software-development-chapter-1/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.synesthesia.co.uk/blog/archives/2003/10/06/study-notes-lean-software-development-chapter-1/</link>
	<description>Notes on stuff</description>
	<lastBuildDate>Mon, 06 Feb 2012 17:15:54 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Phil Wolff</title>
		<link>http://www.synesthesia.co.uk/blog/archives/2003/10/06/study-notes-lean-software-development-chapter-1/comment-page-1/#comment-86</link>
		<dc:creator>Phil Wolff</dc:creator>
		<pubDate>Wed, 30 Nov -0001 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.synesthesia.co.uk/blog/archives/2003/10/06/study-notes-lean-software-development-chapter-1/#comment-86</guid>
		<description>One problem with &quot;customer visibility = value;&quot; most plumbing and housekeeping is horrible to explain in plain language. So much goes into making indirect value instead of hotlist features: reliability, maintainability, administrative functions, availability, speed, ease of use, scalability, security, etc. They all require work and rework but they&#039;re nearly impossible to quantify let alone explain.</description>
		<content:encoded><![CDATA[<p><span class="cocomment-ext-rating" id="cocomment-rating-86"></span>One problem with &#8220;customer visibility = value;&#8221; most plumbing and housekeeping is horrible to explain in plain language. So much goes into making indirect value instead of hotlist features: reliability, maintainability, administrative functions, availability, speed, ease of use, scalability, security, etc. They all require work and rework but they&#8217;re nearly impossible to quantify let alone explain.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Julian Elve</title>
		<link>http://www.synesthesia.co.uk/blog/archives/2003/10/06/study-notes-lean-software-development-chapter-1/comment-page-1/#comment-87</link>
		<dc:creator>Julian Elve</dc:creator>
		<pubDate>Wed, 30 Nov -0001 00:00:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.synesthesia.co.uk/blog/archives/2003/10/06/study-notes-lean-software-development-chapter-1/#comment-87</guid>
		<description>Thanks for your comment Phil.

You are right it can be difficult to excite the end users about those essential &quot;plumbing&quot; features, so a key part of deciding what is important in the project is recognising the whole voice of the customer. For a bespoke or tailored system then the purchaser will have several voices - the end users, the business funders and the &quot;informed purchaser&quot; (typically the customer&#039;s IT management) - certainly as such an &quot;informed purchaser&quot; (I use the phrase slightly ironically!) I try to balance all of those factors into the brief I give to suppliers. I guess that with COTS applications the equivalent would be the vendor&#039;s product management team who are trying to create a longer lifecycle for the product.

In both cases it&#039;s a matter of extending people&#039;s time horizons to look beyond the here/now (e.g. bells and whistles) to think about what they might want to do in the future, or painting scenarios of differing levels of availability to help them understand the importance of the plumbing...
</description>
		<content:encoded><![CDATA[<p><span class="cocomment-ext-rating" id="cocomment-rating-87"></span>Thanks for your comment Phil.</p>
<p>You are right it can be difficult to excite the end users about those essential &#8220;plumbing&#8221; features, so a key part of deciding what is important in the project is recognising the whole voice of the customer. For a bespoke or tailored system then the purchaser will have several voices &#8211; the end users, the business funders and the &#8220;informed purchaser&#8221; (typically the customer&#8217;s IT management) &#8211; certainly as such an &#8220;informed purchaser&#8221; (I use the phrase slightly ironically!) I try to balance all of those factors into the brief I give to suppliers. I guess that with COTS applications the equivalent would be the vendor&#8217;s product management team who are trying to create a longer lifecycle for the product.</p>
<p>In both cases it&#8217;s a matter of extending people&#8217;s time horizons to look beyond the here/now (e.g. bells and whistles) to think about what they might want to do in the future, or painting scenarios of differing levels of availability to help them understand the importance of the plumbing&#8230;</p>
]]></content:encoded>
	</item>
</channel>
</rss>

