<?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: Some Silly Advice</title>
	<atom:link href="http://www.rallydev.com/agileblog/2010/01/some-silly-advice/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.rallydev.com/agileblog/2010/01/some-silly-advice/</link>
	<description>Adopt, Scale and Succeed with Agile Development</description>
	<lastBuildDate>Tue, 10 Jan 2012 03:30:50 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.5</generator>
	<item>
		<title>By: Alexandre Gautheir</title>
		<link>http://www.rallydev.com/agileblog/2010/01/some-silly-advice/#comment-8120</link>
		<dc:creator>Alexandre Gautheir</dc:creator>
		<pubDate>Fri, 26 Nov 2010 16:07:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.rallydev.com/agileblog/?p=4393#comment-8120</guid>
		<description>Enjoyed your post! In my company, &lt;a href=&quot;www.planbox.com&quot; rel=&quot;nofollow&quot;&gt;Planbox&lt;/a&gt; we also believe in continuously improving ourselves!</description>
		<content:encoded><![CDATA[<p>Enjoyed your post! In my company, <a href="www.planbox.com" rel="nofollow">Planbox</a> we also believe in continuously improving ourselves!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: sean</title>
		<link>http://www.rallydev.com/agileblog/2010/01/some-silly-advice/#comment-6320</link>
		<dc:creator>sean</dc:creator>
		<pubDate>Fri, 02 Jul 2010 08:04:22 +0000</pubDate>
		<guid isPermaLink="false">http://www.rallydev.com/agileblog/?p=4393#comment-6320</guid>
		<description>&quot;(1) The most productive developers can be 100%+ more productive other developers...&quot;

More.  The most productive developers are around 1000% as productive as average, whether measured in terms of feature coded, lines of code produced, or bugs found.  Seriously - hit the books, read the research.

IT development is an area in which the best really are much, much, much better than average.</description>
		<content:encoded><![CDATA[<p>&#8220;(1) The most productive developers can be 100%+ more productive other developers&#8230;&#8221;</p>
<p>More.  The most productive developers are around 1000% as productive as average, whether measured in terms of feature coded, lines of code produced, or bugs found.  Seriously &#8211; hit the books, read the research.</p>
<p>IT development is an area in which the best really are much, much, much better than average.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Alan Atlas</title>
		<link>http://www.rallydev.com/agileblog/2010/01/some-silly-advice/#comment-6173</link>
		<dc:creator>Alan Atlas</dc:creator>
		<pubDate>Wed, 09 Jun 2010 20:40:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.rallydev.com/agileblog/?p=4393#comment-6173</guid>
		<description>Hi Craig,

I totally agree with the sentiments expressed in the quote you mention.

When I wrote my blog post, I was actually looking at p. 280, where it says &quot;Try...Hire the best&quot; right there in the middle of the page. You&#039;re right, even this quote makes more sense in the context of its chapter, but there it is. 

I&#039;m looking at it now and I notice on the next page &quot;Avoid...Hiring when you cannot find the best&quot;. 

Those were the things I was responding to in the original blog post.

alan</description>
		<content:encoded><![CDATA[<p>Hi Craig,</p>
<p>I totally agree with the sentiments expressed in the quote you mention.</p>
<p>When I wrote my blog post, I was actually looking at p. 280, where it says &#8220;Try&#8230;Hire the best&#8221; right there in the middle of the page. You&#8217;re right, even this quote makes more sense in the context of its chapter, but there it is. </p>
<p>I&#8217;m looking at it now and I notice on the next page &#8220;Avoid&#8230;Hiring when you cannot find the best&#8221;. </p>
<p>Those were the things I was responding to in the original blog post.</p>
<p>alan</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Craig Larman</title>
		<link>http://www.rallydev.com/agileblog/2010/01/some-silly-advice/#comment-6172</link>
		<dc:creator>Craig Larman</dc:creator>
		<pubDate>Wed, 09 Jun 2010 17:45:51 +0000</pubDate>
		<guid isPermaLink="false">http://www.rallydev.com/agileblog/?p=4393#comment-6172</guid>
		<description>well, what we actually wrote was, &quot;There are better ways to build large systems than with many developers in many places. Rather, build a small group of great developers and other talents that can work together in teams, pay them well, and keep them together in one place with product management or whoever acts as the voice of the customer.&quot;

and our advice needs to be put in the context of who are intended reading audience is: we work in large-scale dev where a typical product is 500-2000 people and -- key point -- the typical &quot;site strategy&quot; of the leadership in our client companies is, &quot;Developers are basically the same everywhere. And if you need to do big work, we need to hire more bodies. So let&#039;s add 700 more people in China to this release, so we can go faster.&quot; Our advice above is a counter to this mindset, and we still stand by it in this context.

regards, craig</description>
		<content:encoded><![CDATA[<p>well, what we actually wrote was, &#8220;There are better ways to build large systems than with many developers in many places. Rather, build a small group of great developers and other talents that can work together in teams, pay them well, and keep them together in one place with product management or whoever acts as the voice of the customer.&#8221;</p>
<p>and our advice needs to be put in the context of who are intended reading audience is: we work in large-scale dev where a typical product is 500-2000 people and &#8212; key point &#8212; the typical &#8220;site strategy&#8221; of the leadership in our client companies is, &#8220;Developers are basically the same everywhere. And if you need to do big work, we need to hire more bodies. So let&#8217;s add 700 more people in China to this release, so we can go faster.&#8221; Our advice above is a counter to this mindset, and we still stand by it in this context.</p>
<p>regards, craig</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tomo Lennox</title>
		<link>http://www.rallydev.com/agileblog/2010/01/some-silly-advice/#comment-5739</link>
		<dc:creator>Tomo Lennox</dc:creator>
		<pubDate>Thu, 15 Apr 2010 03:33:52 +0000</pubDate>
		<guid isPermaLink="false">http://www.rallydev.com/agileblog/?p=4393#comment-5739</guid>
		<description>&quot;Best&quot; may not define the goal very well.  I would say, hire people with lots of experience and ideally lots of experience in different areas.  Having a good percentage of generalists on the team is at the heart of being agile.

Something about current hiring practices seems to look for someone as much like the job description as possible.  Those 6 years in accounting and 2 years in customer support seem to count against you, because they are not in the job description.</description>
		<content:encoded><![CDATA[<p>&#8220;Best&#8221; may not define the goal very well.  I would say, hire people with lots of experience and ideally lots of experience in different areas.  Having a good percentage of generalists on the team is at the heart of being agile.</p>
<p>Something about current hiring practices seems to look for someone as much like the job description as possible.  Those 6 years in accounting and 2 years in customer support seem to count against you, because they are not in the job description.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Earned Lessons &#187; Blog Archive &#187; Hiring is Timing</title>
		<link>http://www.rallydev.com/agileblog/2010/01/some-silly-advice/#comment-5625</link>
		<dc:creator>Earned Lessons &#187; Blog Archive &#187; Hiring is Timing</dc:creator>
		<pubDate>Mon, 15 Mar 2010 21:46:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.rallydev.com/agileblog/?p=4393#comment-5625</guid>
		<description>[...] the things you need them to do. I was reminded that is is better for the organization to &#8220;Hire well, and develop people&#8221; then it is to hire &#8220;The Best&#8221; [...]</description>
		<content:encoded><![CDATA[<p>[...] the things you need them to do. I was reminded that is is better for the organization to &#8220;Hire well, and develop people&#8221; then it is to hire &#8220;The Best&#8221; [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Martin Kearns</title>
		<link>http://www.rallydev.com/agileblog/2010/01/some-silly-advice/#comment-5476</link>
		<dc:creator>Martin Kearns</dc:creator>
		<pubDate>Wed, 10 Feb 2010 01:20:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.rallydev.com/agileblog/?p=4393#comment-5476</guid>
		<description>Hi Alan,

I really enjoyed the article, the biggest danger I noticed with hiring the best is the fact that you create a completely arrogant culture. In fact you are already on your way to group think almost immediately. 

The problem becomes bigger when the group then has not got the ability to resonate with people who are &quot;not the best&quot; which also significantly impacts productivity. 

If such a group is allow to mature, the issues magnify as the fire is now pulling in the fuel to grow bigger. I will only hire people who agree with &quot;the best&quot;.. 

A great article. 

Regards, 
martin.</description>
		<content:encoded><![CDATA[<p>Hi Alan,</p>
<p>I really enjoyed the article, the biggest danger I noticed with hiring the best is the fact that you create a completely arrogant culture. In fact you are already on your way to group think almost immediately. </p>
<p>The problem becomes bigger when the group then has not got the ability to resonate with people who are &#8220;not the best&#8221; which also significantly impacts productivity. </p>
<p>If such a group is allow to mature, the issues magnify as the fire is now pulling in the fuel to grow bigger. I will only hire people who agree with &#8220;the best&#8221;.. </p>
<p>A great article. </p>
<p>Regards,<br />
martin.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jim Holland</title>
		<link>http://www.rallydev.com/agileblog/2010/01/some-silly-advice/#comment-5470</link>
		<dc:creator>Jim Holland</dc:creator>
		<pubDate>Mon, 08 Feb 2010 23:15:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.rallydev.com/agileblog/?p=4393#comment-5470</guid>
		<description>I recently saw a job descriptin that used this term and then asked for a &quot;new perfect&quot; individual. It doesn&#039;t happen. 

Find me an enthusiast, open to learn and apply oriented communicator and I&#039;ll hire that person.

Great post.</description>
		<content:encoded><![CDATA[<p>I recently saw a job descriptin that used this term and then asked for a &#8220;new perfect&#8221; individual. It doesn&#8217;t happen. </p>
<p>Find me an enthusiast, open to learn and apply oriented communicator and I&#8217;ll hire that person.</p>
<p>Great post.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott Schnier</title>
		<link>http://www.rallydev.com/agileblog/2010/01/some-silly-advice/#comment-5394</link>
		<dc:creator>Scott Schnier</dc:creator>
		<pubDate>Wed, 03 Feb 2010 19:24:25 +0000</pubDate>
		<guid isPermaLink="false">http://www.rallydev.com/agileblog/?p=4393#comment-5394</guid>
		<description>The phrase &quot;hire the best&quot; makes me frown. Is there a simple scalar way to rank all the people in a profession so that it is simple to identify the top x%? Consider the work on &quot;multiple intelligences&quot; by thought leaders like Goldman and Garner. I also believe that so much of what makes agile work or not work is very dependent on cultural or environmental factors. So for me it is not obvious or useful advice to &quot;hire the best&quot;. But maybe good advice is to hire the best fit for a position. Some of the best and most productive teams I have been on were comprised of a set of people with very complementary skills and abilities. They were not all the best but they worked well together and complemented one another. If someone were to come up with a model for the geometry of an organization&#039;s culture or a person&#039;s talents and skills so that we could measure &quot;fit&quot; that would be a good discussion.</description>
		<content:encoded><![CDATA[<p>The phrase &#8220;hire the best&#8221; makes me frown. Is there a simple scalar way to rank all the people in a profession so that it is simple to identify the top x%? Consider the work on &#8220;multiple intelligences&#8221; by thought leaders like Goldman and Garner. I also believe that so much of what makes agile work or not work is very dependent on cultural or environmental factors. So for me it is not obvious or useful advice to &#8220;hire the best&#8221;. But maybe good advice is to hire the best fit for a position. Some of the best and most productive teams I have been on were comprised of a set of people with very complementary skills and abilities. They were not all the best but they worked well together and complemented one another. If someone were to come up with a model for the geometry of an organization&#8217;s culture or a person&#8217;s talents and skills so that we could measure &#8220;fit&#8221; that would be a good discussion.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: David</title>
		<link>http://www.rallydev.com/agileblog/2010/01/some-silly-advice/#comment-5347</link>
		<dc:creator>David</dc:creator>
		<pubDate>Mon, 01 Feb 2010 22:04:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.rallydev.com/agileblog/?p=4393#comment-5347</guid>
		<description>Fantastic article!  Engaging teams in the decision making cycle of development has proven valuable in raising quality and improving results. 

The same can be true in hiring.  Involve the team early in the decision process!  This builds morale, the team generally knows what skills the group needs, and it creates a culture where the existing team is willing to invest in the new members into great contributors. 

David</description>
		<content:encoded><![CDATA[<p>Fantastic article!  Engaging teams in the decision making cycle of development has proven valuable in raising quality and improving results. </p>
<p>The same can be true in hiring.  Involve the team early in the decision process!  This builds morale, the team generally knows what skills the group needs, and it creates a culture where the existing team is willing to invest in the new members into great contributors. </p>
<p>David</p>
]]></content:encoded>
	</item>
</channel>
</rss>

