<?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: On Software Requirements: Just say No&#8230; agile is simple</title>
	<atom:link href="http://www.redmonk.com/jgovernor/2007/01/26/on-software-requirements-just-say-no-agile-is-simple/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.redmonk.com/jgovernor/2007/01/26/on-software-requirements-just-say-no-agile-is-simple/</link>
	<description>An industry analyst blog looking at software ecosystems and convergence</description>
	<lastBuildDate>Fri, 03 Feb 2012 10:35:40 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Stephane</title>
		<link>http://www.redmonk.com/jgovernor/2007/01/26/on-software-requirements-just-say-no-agile-is-simple/comment-page-1/#comment-566536</link>
		<dc:creator>Stephane</dc:creator>
		<pubDate>Tue, 23 Nov 2010 12:26:11 +0000</pubDate>
		<guid isPermaLink="false">http://www.redmonk.com/jgovernor/2007/01/26/on-software-requirements-just-say-no-agile-is-simple/#comment-566536</guid>
		<description>Very good post - I totally agree with the point. However, in the middle of an org, if it&#039;s possible to say no to the worst feature requests, it&#039;s really hard to say no to most. I think that a possibility to escape that complexity/bloating trap is to provide some sort of plugin architecture when the context allows it. After all, special feature requests are well... special, so most other customers won&#039;t use it. In this case, providing a plugin for that feature allow the users to be happy without bloating the standard code base. In an extreme scale, this is actually what app stores are also doing.</description>
		<content:encoded><![CDATA[<p>Very good post &#8211; I totally agree with the point. However, in the middle of an org, if it&#8217;s possible to say no to the worst feature requests, it&#8217;s really hard to say no to most. I think that a possibility to escape that complexity/bloating trap is to provide some sort of plugin architecture when the context allows it. After all, special feature requests are well&#8230; special, so most other customers won&#8217;t use it. In this case, providing a plugin for that feature allow the users to be happy without bloating the standard code base. In an extreme scale, this is actually what app stores are also doing.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: James Governor</title>
		<link>http://www.redmonk.com/jgovernor/2007/01/26/on-software-requirements-just-say-no-agile-is-simple/comment-page-1/#comment-566532</link>
		<dc:creator>James Governor</dc:creator>
		<pubDate>Tue, 23 Nov 2010 10:42:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.redmonk.com/jgovernor/2007/01/26/on-software-requirements-just-say-no-agile-is-simple/#comment-566532</guid>
		<description>looking at back at this i have to chuckle. i still think the essential point is sound. apple has shown us all the difference between requirements and great user experience. 37Signals- great at rhetoric, full of useful lessons. but we stopped using its software. that said Ruby on Rails is opinionated software- it does a great job of erring on side of convention rather than configurability. it says no to developers...</description>
		<content:encoded><![CDATA[<p>looking at back at this i have to chuckle. i still think the essential point is sound. apple has shown us all the difference between requirements and great user experience. 37Signals- great at rhetoric, full of useful lessons. but we stopped using its software. that said Ruby on Rails is opinionated software- it does a great job of erring on side of convention rather than configurability. it says no to developers&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: People Over Process &#187; Blog Archive &#187; links for 2007-01-30</title>
		<link>http://www.redmonk.com/jgovernor/2007/01/26/on-software-requirements-just-say-no-agile-is-simple/comment-page-1/#comment-16291</link>
		<dc:creator>People Over Process &#187; Blog Archive &#187; links for 2007-01-30</dc:creator>
		<pubDate>Tue, 30 Jan 2007 07:27:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.redmonk.com/jgovernor/2007/01/26/on-software-requirements-just-say-no-agile-is-simple/#comment-16291</guid>
		<description>[...] On Software Requirements: Just say No… agile is simple Big ups! (tags: agile smellsofagile requirements) [...]</description>
		<content:encoded><![CDATA[<p>[...] On Software Requirements: Just say No… agile is simple Big ups! (tags: agile smellsofagile requirements) [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: People Over Process &#187; Blog Archive &#187; Re: Just Say No&#8230; agile is simple, or, Escape from Your Ghettos, Suits and Coders!</title>
		<link>http://www.redmonk.com/jgovernor/2007/01/26/on-software-requirements-just-say-no-agile-is-simple/comment-page-1/#comment-15951</link>
		<dc:creator>People Over Process &#187; Blog Archive &#187; Re: Just Say No&#8230; agile is simple, or, Escape from Your Ghettos, Suits and Coders!</dc:creator>
		<pubDate>Mon, 29 Jan 2007 23:59:58 +0000</pubDate>
		<guid isPermaLink="false">http://www.redmonk.com/jgovernor/2007/01/26/on-software-requirements-just-say-no-agile-is-simple/#comment-15951</guid>
		<description>[...] Here&#8217;s some commentary to amplify and fortify some of the points in one of James&#8217; recent posts, the thrust of which is that software vendors (and, we&#8217;d assume, projects) need to reject feature requests more often. On the topic of Agile, he adds:  Perhaps we should add this sniff test to the smell of agile - you can tell an organisation is agile when development teams can reject feature requests. [...]</description>
		<content:encoded><![CDATA[<p>[...] Here&#8217;s some commentary to amplify and fortify some of the points in one of James&#8217; recent posts, the thrust of which is that software vendors (and, we&#8217;d assume, projects) need to reject feature requests more often. On the topic of Agile, he adds:  Perhaps we should add this sniff test to the smell of agile &#8211; you can tell an organisation is agile when development teams can reject feature requests. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Paul Cooper</title>
		<link>http://www.redmonk.com/jgovernor/2007/01/26/on-software-requirements-just-say-no-agile-is-simple/comment-page-1/#comment-15808</link>
		<dc:creator>Paul Cooper</dc:creator>
		<pubDate>Mon, 29 Jan 2007 11:42:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.redmonk.com/jgovernor/2007/01/26/on-software-requirements-just-say-no-agile-is-simple/#comment-15808</guid>
		<description>Although I&#039;ve never worked for an &#039;Enterprise&#039;, in my experience with small business one of the advantages of an agile approach is that it helps the customer say no - to be able to take their list of 20+ must have features and say, &#039;in a month I will deliver a working app but with only 2-5 of those features, so which are the most important&#039; helps them very quickly discard the fat - and while it might be hard the first go round the cycle, once they become accustomed the list of required features get shorter and more focused over time.</description>
		<content:encoded><![CDATA[<p>Although I&#8217;ve never worked for an &#8216;Enterprise&#8217;, in my experience with small business one of the advantages of an agile approach is that it helps the customer say no &#8211; to be able to take their list of 20+ must have features and say, &#8216;in a month I will deliver a working app but with only 2-5 of those features, so which are the most important&#8217; helps them very quickly discard the fat &#8211; and while it might be hard the first go round the cycle, once they become accustomed the list of required features get shorter and more focused over time.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: dan mcweeney</title>
		<link>http://www.redmonk.com/jgovernor/2007/01/26/on-software-requirements-just-say-no-agile-is-simple/comment-page-1/#comment-14822</link>
		<dc:creator>dan mcweeney</dc:creator>
		<pubDate>Fri, 26 Jan 2007 21:02:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.redmonk.com/jgovernor/2007/01/26/on-software-requirements-just-say-no-agile-is-simple/#comment-14822</guid>
		<description>Darn forgot my creative commons license disclaimer on that post... ;-)</description>
		<content:encoded><![CDATA[<p>Darn forgot my creative commons license disclaimer on that post&#8230; <img src='http://www.redmonk.com/jgovernor/wp/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Berkay Mollamustafao</title>
		<link>http://www.redmonk.com/jgovernor/2007/01/26/on-software-requirements-just-say-no-agile-is-simple/comment-page-1/#comment-14795</link>
		<dc:creator>Berkay Mollamustafao</dc:creator>
		<pubDate>Fri, 26 Jan 2007 20:06:04 +0000</pubDate>
		<guid isPermaLink="false">http://www.redmonk.com/jgovernor/2007/01/26/on-software-requirements-just-say-no-agile-is-simple/#comment-14795</guid>
		<description>Point taken.  I&#039;m sure many developers who are shaking their heads because of a crazy feature request will sympathize. 
In fact, I think the real problem is developers talking to middle man (sales folks, etc.) rather than having direct access to the users to understand what they need. 

It is actually the second time I&#039;ve commented :)</description>
		<content:encoded><![CDATA[<p>Point taken.  I&#8217;m sure many developers who are shaking their heads because of a crazy feature request will sympathize.<br />
In fact, I think the real problem is developers talking to middle man (sales folks, etc.) rather than having direct access to the users to understand what they need. </p>
<p>It is actually the second time I&#8217;ve commented <img src='http://www.redmonk.com/jgovernor/wp/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: jgovernor</title>
		<link>http://www.redmonk.com/jgovernor/2007/01/26/on-software-requirements-just-say-no-agile-is-simple/comment-page-1/#comment-14729</link>
		<dc:creator>jgovernor</dc:creator>
		<pubDate>Fri, 26 Jan 2007 17:35:46 +0000</pubDate>
		<guid isPermaLink="false">http://www.redmonk.com/jgovernor/2007/01/26/on-software-requirements-just-say-no-agile-is-simple/#comment-14729</guid>
		<description>Cheers Dan- i love that analogy. may have to ahem repurpose it for monkchips...

Berkay - there is a first time for everything, and i believe this is also the first time you have commented here, so i am actually glad i said something you feel strongly about. I really meant 37Signals as an edge-case that tells us something, rather than as a formal recommendation their approach is the only one worth taking.

I am a big believer in talking and the primary point of the post was to say orgs should listen to developers they may have something valuable to say. The notion that every feature request must be met makes no sense. 

But I am very glad to have you both commenting.</description>
		<content:encoded><![CDATA[<p>Cheers Dan- i love that analogy. may have to ahem repurpose it for monkchips&#8230;</p>
<p>Berkay &#8211; there is a first time for everything, and i believe this is also the first time you have commented here, so i am actually glad i said something you feel strongly about. I really meant 37Signals as an edge-case that tells us something, rather than as a formal recommendation their approach is the only one worth taking.</p>
<p>I am a big believer in talking and the primary point of the post was to say orgs should listen to developers they may have something valuable to say. The notion that every feature request must be met makes no sense. </p>
<p>But I am very glad to have you both commenting.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Berkay Mollamustafao</title>
		<link>http://www.redmonk.com/jgovernor/2007/01/26/on-software-requirements-just-say-no-agile-is-simple/comment-page-1/#comment-14698</link>
		<dc:creator>Berkay Mollamustafao</dc:creator>
		<pubDate>Fri, 26 Jan 2007 16:14:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.redmonk.com/jgovernor/2007/01/26/on-software-requirements-just-say-no-agile-is-simple/#comment-14698</guid>
		<description>I can&#039;t believe you buy into the junk coming out of 37Signals, let along you promote it. First time I find myself disagreeing with what James writes on this blog.

IMHO, brilliant folks in 37Signals suffer from (or guilty of) generalizing based on small set of data. &quot;read them and throw them away&quot;? what happened to conversations, having direct access to customers? http://www.redmonk.com/cote/2007/01/25/5-tips-for-systems-management-20-folks/
Wonder Cote agrees with this suggestion. 

Ignoring your customers and listening to your software developers may only be a option when your developers are natural consumers of the products they&#039;re developing.  

If not (which is the case for many many software developers, dare I say most) , how would the developers know what&#039;s important, what the users need? 
I strongly recommend Eric Sink&#039;s article on this topic, usware vs themware http://www.ericsink.com/articles/Yours_Mine_Ours.html

Sure the developers should be able to reject feature requests but it&#039;s much better to err on listening customers especially if you&#039;re developing themware

Ignoring your customers makes a sensational headline which works great for 37Signals, but it has so nothing to do with agile!</description>
		<content:encoded><![CDATA[<p>I can&#8217;t believe you buy into the junk coming out of 37Signals, let along you promote it. First time I find myself disagreeing with what James writes on this blog.</p>
<p>IMHO, brilliant folks in 37Signals suffer from (or guilty of) generalizing based on small set of data. &#8220;read them and throw them away&#8221;? what happened to conversations, having direct access to customers? <a href="http://www.redmonk.com/cote/2007/01/25/5-tips-for-systems-management-20-folks/" rel="nofollow">http://www.redmonk.com/cote/2007/01/25/5-tips-for-systems-management-20-folks/</a><br />
Wonder Cote agrees with this suggestion. </p>
<p>Ignoring your customers and listening to your software developers may only be a option when your developers are natural consumers of the products they&#8217;re developing.  </p>
<p>If not (which is the case for many many software developers, dare I say most) , how would the developers know what&#8217;s important, what the users need?<br />
I strongly recommend Eric Sink&#8217;s article on this topic, usware vs themware <a href="http://www.ericsink.com/articles/Yours_Mine_Ours.html" rel="nofollow">http://www.ericsink.com/articles/Yours_Mine_Ours.html</a></p>
<p>Sure the developers should be able to reject feature requests but it&#8217;s much better to err on listening customers especially if you&#8217;re developing themware</p>
<p>Ignoring your customers makes a sensational headline which works great for 37Signals, but it has so nothing to do with agile!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: dan mcweeney</title>
		<link>http://www.redmonk.com/jgovernor/2007/01/26/on-software-requirements-just-say-no-agile-is-simple/comment-page-1/#comment-14669</link>
		<dc:creator>dan mcweeney</dc:creator>
		<pubDate>Fri, 26 Jan 2007 15:25:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.redmonk.com/jgovernor/2007/01/26/on-software-requirements-just-say-no-agile-is-simple/#comment-14669</guid>
		<description>This gets nearly impossible when you work in Enterprise software because your customers ( the business ) work for the same company and decide your budget for next year so, people feel like &quot;No&quot; isn&#039;t an option.  So, I resort to the following analogy:

We have two options we can sit here and talk about building a huge massive cruise ship with staterooms and multiple dining areas, maybe even a rock wall then launch it and realize to everyone&#039;s horror that we weren&#039;t launching the ship into water, but something that looked like water but with totally different properties.
OR
I can quickly build a row boat and send it out on the lake, when that sinks we lose one person ( boo-hoo ) and have learned a vast amount in a shorter time.  We can now launch a better designed ferry that carries most of our group and cross the lake, all before the cruise ship even launches once.
-d</description>
		<content:encoded><![CDATA[<p>This gets nearly impossible when you work in Enterprise software because your customers ( the business ) work for the same company and decide your budget for next year so, people feel like &#8220;No&#8221; isn&#8217;t an option.  So, I resort to the following analogy:</p>
<p>We have two options we can sit here and talk about building a huge massive cruise ship with staterooms and multiple dining areas, maybe even a rock wall then launch it and realize to everyone&#8217;s horror that we weren&#8217;t launching the ship into water, but something that looked like water but with totally different properties.<br />
OR<br />
I can quickly build a row boat and send it out on the lake, when that sinks we lose one person ( boo-hoo ) and have learned a vast amount in a shorter time.  We can now launch a better designed ferry that carries most of our group and cross the lake, all before the cruise ship even launches once.<br />
-d</p>
]]></content:encoded>
	</item>
</channel>
</rss>

