<?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: New to agile?  Remember how to say &#8220;No&#8221;</title>
	<atom:link href="http://www.agileforall.com/2009/05/18/new-to-agile-remember-how-to-say-no/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.agileforall.com/2009/05/18/new-to-agile-remember-how-to-say-no/</link>
	<description>Agile For All</description>
	<lastBuildDate>Fri, 13 Jan 2012 18:11:43 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Adriana B.</title>
		<link>http://www.agileforall.com/2009/05/18/new-to-agile-remember-how-to-say-no/comment-page-1/#comment-233</link>
		<dc:creator>Adriana B.</dc:creator>
		<pubDate>Sun, 24 May 2009 15:09:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.agileforall.com/?p=881#comment-233</guid>
		<description>I agree with Bob. Saying yes and then not delivering is worse from all perspectives than saying no to an unreasonable request. Good risk management is important in every project, but it won&#039;t make a &quot;no&quot; become a &quot;yes&quot; if time, cost, lack of enough information upfront, or another constraint, makes it impossible to fulfill a request without causing a negative impact in the project.

The book &quot;NO: The only negotiating system you need for work and home&quot;, by Jim Camp, is a good reference for people who is constantly trying to please others with a yes: 

&quot;Saying &#039;no&#039; is not about being hard-nosed or intransigent. Rather, it stops everyone in their tracks, clears the air, and allows you to get at what the real issues are. It is a proven and an amazing effective system that avoids unwarranted assumptions, needless compromises, and wild guesses.&quot;</description>
		<content:encoded><![CDATA[<p>I agree with Bob. Saying yes and then not delivering is worse from all perspectives than saying no to an unreasonable request. Good risk management is important in every project, but it won&#8217;t make a &#8220;no&#8221; become a &#8220;yes&#8221; if time, cost, lack of enough information upfront, or another constraint, makes it impossible to fulfill a request without causing a negative impact in the project.</p>
<p>The book &#8220;NO: The only negotiating system you need for work and home&#8221;, by Jim Camp, is a good reference for people who is constantly trying to please others with a yes: </p>
<p>&#8220;Saying &#8216;no&#8217; is not about being hard-nosed or intransigent. Rather, it stops everyone in their tracks, clears the air, and allows you to get at what the real issues are. It is a proven and an amazing effective system that avoids unwarranted assumptions, needless compromises, and wild guesses.&#8221;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bob Hartman</title>
		<link>http://www.agileforall.com/2009/05/18/new-to-agile-remember-how-to-say-no/comment-page-1/#comment-229</link>
		<dc:creator>Bob Hartman</dc:creator>
		<pubDate>Fri, 22 May 2009 00:57:56 +0000</pubDate>
		<guid isPermaLink="false">http://www.agileforall.com/?p=881#comment-229</guid>
		<description>Vin, I&#039;m going to disagree with you on this.  There are many times when teams need to say no because saying yes implies it will get done, when in truth something will fall out (which is something you said yes to previously).  I think it is dangerous for the team to say yes and then just prioritize their way out of the mess.

This also doesn&#039;t necessarily work when evaluating which projects should actually be done, whether a portfolio of products has the necessary ROI, etc.  In those cases you run the risk of throwing good money away after you&#039;ve already spent a bunch of money.

I may be wrong, but in my experience teams and organizations who use &quot;no&quot; effectively are the best performing in terms of ROI.

- Bob -</description>
		<content:encoded><![CDATA[<p>Vin, I&#8217;m going to disagree with you on this.  There are many times when teams need to say no because saying yes implies it will get done, when in truth something will fall out (which is something you said yes to previously).  I think it is dangerous for the team to say yes and then just prioritize their way out of the mess.</p>
<p>This also doesn&#8217;t necessarily work when evaluating which projects should actually be done, whether a portfolio of products has the necessary ROI, etc.  In those cases you run the risk of throwing good money away after you&#8217;ve already spent a bunch of money.</p>
<p>I may be wrong, but in my experience teams and organizations who use &#8220;no&#8221; effectively are the best performing in terms of ROI.</p>
<p>- Bob -</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Vin D'Amico</title>
		<link>http://www.agileforall.com/2009/05/18/new-to-agile-remember-how-to-say-no/comment-page-1/#comment-225</link>
		<dc:creator>Vin D'Amico</dc:creator>
		<pubDate>Wed, 20 May 2009 02:18:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.agileforall.com/?p=881#comment-225</guid>
		<description>No, no, no. Don&#039;t say no.

Say yes! Then prioritize and assess risk. In fact, risk management is the best way to say yes while staying focused on what really matters.

Saying no will get you labeled as difficult and uncooperative. Saying yes and educating people about the realities of the situation will win respect.</description>
		<content:encoded><![CDATA[<p>No, no, no. Don&#8217;t say no.</p>
<p>Say yes! Then prioritize and assess risk. In fact, risk management is the best way to say yes while staying focused on what really matters.</p>
<p>Saying no will get you labeled as difficult and uncooperative. Saying yes and educating people about the realities of the situation will win respect.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

