<?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/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: No Wonder Agile Guys Shun Tools</title>
	<atom:link href="http://nigelonagile.com/2010/04/27/no-wonder-agile-guys-shun-tools/feed/" rel="self" type="application/rss+xml" />
	<link>http://nigelonagile.com/2010/04/27/no-wonder-agile-guys-shun-tools/</link>
	<description>Software Engineering and Project Management on the Microsoft Platform</description>
	<lastBuildDate>Wed, 21 Mar 2012 03:44:39 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: 敏捷社区对使用工具过于敏感 &#124; chainding</title>
		<link>http://nigelonagile.com/2010/04/27/no-wonder-agile-guys-shun-tools/#comment-252</link>
		<dc:creator><![CDATA[敏捷社区对使用工具过于敏感 &#124; chainding]]></dc:creator>
		<pubDate>Wed, 21 Mar 2012 03:44:39 +0000</pubDate>
		<guid isPermaLink="false">http://nigelshaw.wordpress.com/2010/04/27/no-wonder-agile-practitioners-shun-tools/#comment-252</guid>
		<description><![CDATA[[...] 但是坚持使用索引卡片、白板和面对面沟通的敏捷人士，他们强调使用这些工具和技术的好处胜过使用软件工具。关于实物敏捷看板和软件工具哪个更好，Nigel Shaw在2010年写过一篇文章，在细微处对比了实物看板和虚拟看板，介绍了使用实物看板比之软件工具具有的优点。他列出了一份清单： [...]]]></description>
		<content:encoded><![CDATA[<p>[...] 但是坚持使用索引卡片、白板和面对面沟通的敏捷人士，他们强调使用这些工具和技术的好处胜过使用软件工具。关于实物敏捷看板和软件工具哪个更好，Nigel Shaw在2010年写过一篇文章，在细微处对比了实物看板和虚拟看板，介绍了使用实物看板比之软件工具具有的优点。他列出了一份清单： [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Brandon Carlson</title>
		<link>http://nigelonagile.com/2010/04/27/no-wonder-agile-guys-shun-tools/#comment-208</link>
		<dc:creator><![CDATA[Brandon Carlson]]></dc:creator>
		<pubDate>Mon, 25 Apr 2011 03:34:32 +0000</pubDate>
		<guid isPermaLink="false">http://nigelshaw.wordpress.com/2010/04/27/no-wonder-agile-practitioners-shun-tools/#comment-208</guid>
		<description><![CDATA[You forgot one of my favorite features of physical boards. If the card hasn&#039;t been touched in months and falls off the board underneath a filing cabinet we&#039;ve successfully cut scope! :-)]]></description>
		<content:encoded><![CDATA[<p>You forgot one of my favorite features of physical boards. If the card hasn&#8217;t been touched in months and falls off the board underneath a filing cabinet we&#8217;ve successfully cut scope! <img src='http://s0.wp.com/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Carroll Snow</title>
		<link>http://nigelonagile.com/2010/04/27/no-wonder-agile-guys-shun-tools/#comment-46</link>
		<dc:creator><![CDATA[Carroll Snow]]></dc:creator>
		<pubDate>Sun, 30 May 2010 06:01:12 +0000</pubDate>
		<guid isPermaLink="false">http://nigelshaw.wordpress.com/2010/04/27/no-wonder-agile-practitioners-shun-tools/#comment-46</guid>
		<description><![CDATA[Haha I&#039;m really the only reply to your incredible read.]]></description>
		<content:encoded><![CDATA[<p>Haha I&#8217;m really the only reply to your incredible read.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Agile Quick Links #14 &#8211; nemrac.com</title>
		<link>http://nigelonagile.com/2010/04/27/no-wonder-agile-guys-shun-tools/#comment-31</link>
		<dc:creator><![CDATA[Agile Quick Links #14 &#8211; nemrac.com]]></dc:creator>
		<pubDate>Thu, 06 May 2010 08:52:23 +0000</pubDate>
		<guid isPermaLink="false">http://nigelshaw.wordpress.com/2010/04/27/no-wonder-agile-practitioners-shun-tools/#comment-31</guid>
		<description><![CDATA[[...] Shaw writes: No Wonder Agile Guys Shun Tools in it he lists some of the many ways that agile tools fail in their attempt to mimic whiteboards. I [...]]]></description>
		<content:encoded><![CDATA[<p>[...] Shaw writes: No Wonder Agile Guys Shun Tools in it he lists some of the many ways that agile tools fail in their attempt to mimic whiteboards. I [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Vineet Sinha</title>
		<link>http://nigelonagile.com/2010/04/27/no-wonder-agile-guys-shun-tools/#comment-29</link>
		<dc:creator><![CDATA[Vineet Sinha]]></dc:creator>
		<pubDate>Fri, 30 Apr 2010 04:42:56 +0000</pubDate>
		<guid isPermaLink="false">http://nigelshaw.wordpress.com/2010/04/27/no-wonder-agile-practitioners-shun-tools/#comment-29</guid>
		<description><![CDATA[Alan,
Great points. It is just that we have not had many people who did the hard work needed to build such systems.

Perhaps the challenge that we really have is that most software developers build tools only for their own needs. It might be the case that all we need is some teams building tools thinking about the developers who would be using it - including how easy it would be for them to learn and use all the features.

Vineet Sinha
Founder, Architexa (http://www.architexa.com)]]></description>
		<content:encoded><![CDATA[<p>Alan,<br />
Great points. It is just that we have not had many people who did the hard work needed to build such systems.</p>
<p>Perhaps the challenge that we really have is that most software developers build tools only for their own needs. It might be the case that all we need is some teams building tools thinking about the developers who would be using it &#8211; including how easy it would be for them to learn and use all the features.</p>
<p>Vineet Sinha<br />
Founder, Architexa (<a href="http://www.architexa.com" rel="nofollow">http://www.architexa.com</a>)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: nigelshaw</title>
		<link>http://nigelonagile.com/2010/04/27/no-wonder-agile-guys-shun-tools/#comment-28</link>
		<dc:creator><![CDATA[nigelshaw]]></dc:creator>
		<pubDate>Fri, 30 Apr 2010 02:34:03 +0000</pubDate>
		<guid isPermaLink="false">http://nigelshaw.wordpress.com/2010/04/27/no-wonder-agile-practitioners-shun-tools/#comment-28</guid>
		<description><![CDATA[Thanks Mark. Much appreciated.]]></description>
		<content:encoded><![CDATA[<p>Thanks Mark. Much appreciated.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark Levison</title>
		<link>http://nigelonagile.com/2010/04/27/no-wonder-agile-guys-shun-tools/#comment-26</link>
		<dc:creator><![CDATA[Mark Levison]]></dc:creator>
		<pubDate>Thu, 29 Apr 2010 09:48:57 +0000</pubDate>
		<guid isPermaLink="false">http://nigelshaw.wordpress.com/2010/04/27/no-wonder-agile-practitioners-shun-tools/#comment-26</guid>
		<description><![CDATA[An interesting post - I will feature in an upcoming Agile Quick Links. As good as you make a tool displayed on a screen, it will still suffer from the problem that no one looks at the webpage very often. People walk past a physical story board many times a day, during standup they can touch the stories they worked on. Finally when someone comes up with a bright new idea for the board you implement it minutes with tape, PostIt Notes and white board marker.

I wish you all the best with this project - it sounds like you have the right spirit.

Cheers
Mark Levison
&lt;a href=&quot;http://Agilepainrelief.com/&quot; rel=&quot;nofollow&quot;&gt;Agile Pain Relief Consulting&lt;/a&gt;]]></description>
		<content:encoded><![CDATA[<p>An interesting post &#8211; I will feature in an upcoming Agile Quick Links. As good as you make a tool displayed on a screen, it will still suffer from the problem that no one looks at the webpage very often. People walk past a physical story board many times a day, during standup they can touch the stories they worked on. Finally when someone comes up with a bright new idea for the board you implement it minutes with tape, PostIt Notes and white board marker.</p>
<p>I wish you all the best with this project &#8211; it sounds like you have the right spirit.</p>
<p>Cheers<br />
Mark Levison<br />
<a href="http://Agilepainrelief.com/" rel="nofollow">Agile Pain Relief Consulting</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: nigelshaw</title>
		<link>http://nigelonagile.com/2010/04/27/no-wonder-agile-guys-shun-tools/#comment-25</link>
		<dc:creator><![CDATA[nigelshaw]]></dc:creator>
		<pubDate>Wed, 28 Apr 2010 18:08:04 +0000</pubDate>
		<guid isPermaLink="false">http://nigelshaw.wordpress.com/2010/04/27/no-wonder-agile-practitioners-shun-tools/#comment-25</guid>
		<description><![CDATA[Thanks Maurice. The balance between the Agile process and the tools is really the essence of the problem wouldn&#039;t you say? At Exia we&#039;re focused on this balance a lot. I think everyone would agree there&#039;s a place for tools, but how much tooling, at what point, and what for? We&#039;re experimenting with ways to design the tool that offer more flexibility in the way you use them. But that&#039;s not enough, because as you say, people will start to go down the tool path too soon. So we&#039;re hoping we can develope nuance or detail of the tool UI that helps alleviate that problem. 

For instance, why don&#039;t people get carried away with detail on a 4x6 card? They just run out of room. So creating a software system where you can type endlessly on the card perhaps invites the type of behaviour you&#039;re referring to. People will start go down the tool path further than they would if the tool had the restrictions of the white board. It&#039;s another characteristic of the white board approach we can add to our list: &quot;The white board restricts the amounts of content.&quot; 

With that thought in mind, we can probably think of many other ways that the white board is restrictive, and where those restrictions are good things that help the Agile process stay on track. So the software should perhaps be equally restrictive if it is to be successful. This highlights the problem we&#039;re focused on at Exia... why don&#039;t Agile and Microsoft Team Sytem get along? Because Team System has too many fields and places so few restrictions on what you can do. It&#039;s an odd paradox... the paradox of choice. 

It&#039;s the same reason we sometimes long for the days when there was just Crest and Colgate, and you picked one or the other and got the heck out of the supermarket a lot faster! Nowadays the Agile team wants the toothpaste that does the least damage to the environment and is the most healthy, while the development team wants the one that brightens your teeth, freshens your breath, disinfects your gums, combats gingevitis, and gets the girl, all at the same time! Amazingly they sell that exact thing. 

The difference in the problem space is this: software is expensive and toothpaste is cheap. If toothpaste cost the same as software and we had to make a collective decision we&#039;d be stuck in the aisle for a week!]]></description>
		<content:encoded><![CDATA[<p>Thanks Maurice. The balance between the Agile process and the tools is really the essence of the problem wouldn&#8217;t you say? At Exia we&#8217;re focused on this balance a lot. I think everyone would agree there&#8217;s a place for tools, but how much tooling, at what point, and what for? We&#8217;re experimenting with ways to design the tool that offer more flexibility in the way you use them. But that&#8217;s not enough, because as you say, people will start to go down the tool path too soon. So we&#8217;re hoping we can develope nuance or detail of the tool UI that helps alleviate that problem. </p>
<p>For instance, why don&#8217;t people get carried away with detail on a 4&#215;6 card? They just run out of room. So creating a software system where you can type endlessly on the card perhaps invites the type of behaviour you&#8217;re referring to. People will start go down the tool path further than they would if the tool had the restrictions of the white board. It&#8217;s another characteristic of the white board approach we can add to our list: &#8220;The white board restricts the amounts of content.&#8221; </p>
<p>With that thought in mind, we can probably think of many other ways that the white board is restrictive, and where those restrictions are good things that help the Agile process stay on track. So the software should perhaps be equally restrictive if it is to be successful. This highlights the problem we&#8217;re focused on at Exia&#8230; why don&#8217;t Agile and Microsoft Team Sytem get along? Because Team System has too many fields and places so few restrictions on what you can do. It&#8217;s an odd paradox&#8230; the paradox of choice. </p>
<p>It&#8217;s the same reason we sometimes long for the days when there was just Crest and Colgate, and you picked one or the other and got the heck out of the supermarket a lot faster! Nowadays the Agile team wants the toothpaste that does the least damage to the environment and is the most healthy, while the development team wants the one that brightens your teeth, freshens your breath, disinfects your gums, combats gingevitis, and gets the girl, all at the same time! Amazingly they sell that exact thing. </p>
<p>The difference in the problem space is this: software is expensive and toothpaste is cheap. If toothpaste cost the same as software and we had to make a collective decision we&#8217;d be stuck in the aisle for a week!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Maurice le Rutte</title>
		<link>http://nigelonagile.com/2010/04/27/no-wonder-agile-guys-shun-tools/#comment-24</link>
		<dc:creator><![CDATA[Maurice le Rutte]]></dc:creator>
		<pubDate>Wed, 28 Apr 2010 07:30:58 +0000</pubDate>
		<guid isPermaLink="false">http://nigelshaw.wordpress.com/2010/04/27/no-wonder-agile-practitioners-shun-tools/#comment-24</guid>
		<description><![CDATA[A project manager type will push/pull regardless of the level of toolingness. I also have seen people work very nicely with digital burndows. So as always... &#039;it depends&#039;]]></description>
		<content:encoded><![CDATA[<p>A project manager type will push/pull regardless of the level of toolingness. I also have seen people work very nicely with digital burndows. So as always&#8230; &#8216;it depends&#8217;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: YvesHanoulle</title>
		<link>http://nigelonagile.com/2010/04/27/no-wonder-agile-guys-shun-tools/#comment-23</link>
		<dc:creator><![CDATA[YvesHanoulle]]></dc:creator>
		<pubDate>Wed, 28 Apr 2010 07:12:09 +0000</pubDate>
		<guid isPermaLink="false">http://nigelshaw.wordpress.com/2010/04/27/no-wonder-agile-practitioners-shun-tools/#comment-23</guid>
		<description><![CDATA[@Tim: having the developers create the burn down chart, makes them relise much more if they are going to make it or not.
Having a digital burndown chart, won&#039;t help them.
(It wil only make a project manager type push/pull them more)]]></description>
		<content:encoded><![CDATA[<p>@Tim: having the developers create the burn down chart, makes them relise much more if they are going to make it or not.<br />
Having a digital burndown chart, won&#8217;t help them.<br />
(It wil only make a project manager type push/pull them more)</p>
]]></content:encoded>
	</item>
</channel>
</rss>

