<?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 for The Daily Standup</title>
	<atom:link href="http://thedailystandup.com/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://thedailystandup.com</link>
	<description>Practical advice for stress free agile project management.</description>
	<lastBuildDate>Mon, 27 Jul 2009 17:55:58 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>Comment on Do unmade decisions cause you stress? by Peter Edstrom</title>
		<link>http://thedailystandup.com/2009/07/26/last-responsible-moment-vs-gtd-unmade-decisions-cause-stress/#comment-183</link>
		<dc:creator>Peter Edstrom</dc:creator>
		<pubDate>Mon, 27 Jul 2009 17:55:58 +0000</pubDate>
		<guid isPermaLink="false">http://thedailystandup.com/?p=110#comment-183</guid>
		<description>I think the stress depends on the type of unmade decision. Things like emails in your inbox ... absolutely cause low-grade stress. Things like framework decisions ... not as much.

With email, you have all available information needed to delete/delegate/respond/defer or do. And by not choosing one, the stress starts. YOU are the only one that can make the call, and you aren&#039;t.  With things like a framework decision (or any other project-related decision) there might be some stress, but I think it is easier to not own the stress. IE, _we_ have not decided on a framework yet; the _business_ hasn&#039;t gotten the requirements to us yet; etc. It simply isn&#039;t time yet to make the call. OTOH, you might have a manager that isn&#039;t keen on waiting, in which case there is stress (YOU don&#039;t have the requirements, because YOU didn&#039;t follow up with the business; etc.)  Though I would put the source of that stress on the manager - not on the principle of deferring the decision to the last moment.</description>
		<content:encoded><![CDATA[<p>I think the stress depends on the type of unmade decision. Things like emails in your inbox &#8230; absolutely cause low-grade stress. Things like framework decisions &#8230; not as much.</p>
<p>With email, you have all available information needed to delete/delegate/respond/defer or do. And by not choosing one, the stress starts. YOU are the only one that can make the call, and you aren&#8217;t.  With things like a framework decision (or any other project-related decision) there might be some stress, but I think it is easier to not own the stress. IE, _we_ have not decided on a framework yet; the _business_ hasn&#8217;t gotten the requirements to us yet; etc. It simply isn&#8217;t time yet to make the call. OTOH, you might have a manager that isn&#8217;t keen on waiting, in which case there is stress (YOU don&#8217;t have the requirements, because YOU didn&#8217;t follow up with the business; etc.)  Though I would put the source of that stress on the manager &#8211; not on the principle of deferring the decision to the last moment.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Do unmade decisions cause you stress? by Ed</title>
		<link>http://thedailystandup.com/2009/07/26/last-responsible-moment-vs-gtd-unmade-decisions-cause-stress/#comment-182</link>
		<dc:creator>Ed</dc:creator>
		<pubDate>Mon, 27 Jul 2009 00:26:24 +0000</pubDate>
		<guid isPermaLink="false">http://thedailystandup.com/?p=110#comment-182</guid>
		<description>Thanks Kourosh. I agree, having a waiting for task is very helpful when someone says &quot;I&#039;ll get back to you.&quot; One practice that has helped me is adding the date when I will follow up with them in the text of my &quot;waiting for&quot; task, in case they forget to get back. Then I&#039;ll catch this in my weekly review (assuming I&#039;m not slacking on that. ^_^)</description>
		<content:encoded><![CDATA[<p>Thanks Kourosh. I agree, having a waiting for task is very helpful when someone says &#8220;I&#8217;ll get back to you.&#8221; One practice that has helped me is adding the date when I will follow up with them in the text of my &#8220;waiting for&#8221; task, in case they forget to get back. Then I&#8217;ll catch this in my weekly review (assuming I&#8217;m not slacking on that. ^_^)</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Do unmade decisions cause you stress? by Kourosh</title>
		<link>http://thedailystandup.com/2009/07/26/last-responsible-moment-vs-gtd-unmade-decisions-cause-stress/#comment-181</link>
		<dc:creator>Kourosh</dc:creator>
		<pubDate>Sun, 26 Jul 2009 15:31:26 +0000</pubDate>
		<guid isPermaLink="false">http://thedailystandup.com/?p=110#comment-181</guid>
		<description>I think you&#039;re spot on in terms of the tickler as being useful to trigger when you need to make a decision.  Another scenario though would be that you are waiting for additional information.  In this case you could consider a &quot;waiting for ...&quot; context to defer until that information is received.</description>
		<content:encoded><![CDATA[<p>I think you&#8217;re spot on in terms of the tickler as being useful to trigger when you need to make a decision.  Another scenario though would be that you are waiting for additional information.  In this case you could consider a &#8220;waiting for &#8230;&#8221; context to defer until that information is received.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on David Anderson Speaks at Bay Area APLN by César</title>
		<link>http://thedailystandup.com/2008/11/05/david-anderson-speaks-at-bay-area-apln/#comment-27</link>
		<dc:creator>César</dc:creator>
		<pubDate>Tue, 11 Nov 2008 20:14:49 +0000</pubDate>
		<guid isPermaLink="false">http://thedailystandup.com/?p=31#comment-27</guid>
		<description>It&#039;s great to know that you enjoyed the event. I could also relate to his story about &quot;giving the team permission to write zero-bug code&quot;.

Afterwards I had a conversation with David and we covered a similar theme to what you share on this post. It&#039;s powerful to give that permission but it often has to come accompanied by a recognition (and removal) of fundamental blocks. 

Such &quot;iron triangles&quot; as you put it must be identified and resolved. This is often non-trivial because they can be caused by enterprise-wide policies or constraints. Worse still, you may be the only one who can see them as the problem they really are and it takes a while for others to come around...

César.</description>
		<content:encoded><![CDATA[<p>It&#8217;s great to know that you enjoyed the event. I could also relate to his story about &#8220;giving the team permission to write zero-bug code&#8221;.</p>
<p>Afterwards I had a conversation with David and we covered a similar theme to what you share on this post. It&#8217;s powerful to give that permission but it often has to come accompanied by a recognition (and removal) of fundamental blocks. </p>
<p>Such &#8220;iron triangles&#8221; as you put it must be identified and resolved. This is often non-trivial because they can be caused by enterprise-wide policies or constraints. Worse still, you may be the only one who can see them as the problem they really are and it takes a while for others to come around&#8230;</p>
<p>César.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

