<?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: Agile Question: Where is the satisfaction?</title>
	<atom:link href="http://www.fuzzylizard.com/archives/2006/12/04/837/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.fuzzylizard.com/archives/2006/12/04/837/</link>
	<description>Web development and design with a little VFX thrown in for fun</description>
	<lastBuildDate>Fri, 14 Jan 2011 22:45:58 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: I.G.</title>
		<link>http://www.fuzzylizard.com/archives/2006/12/04/837/comment-page-1/#comment-8077</link>
		<dc:creator>I.G.</dc:creator>
		<pubDate>Wed, 06 Dec 2006 17:59:12 +0000</pubDate>
		<guid isPermaLink="false">http://www.fuzzylizard.com/archives/2006/12/04/837/#comment-8077</guid>
		<description>That&#039;s a good point that you bring up. I can see that happening particularly if the managers themselves haven&#039;t gone up the chain of ranks from developer to manager. Because our managers can likely also be ITM graduates. It also depends on how the company is structured. Our VP is in direct contact with the developer&#039;s managers and everything seems to go through him. So the control there is more stringent. The VP is also in direct contact with the clients which is advantageous but, I would say the managers who have a developer background, rather than a business background, would probably be able to better gauge efforts and time frames better. Then the question becomes what makes a good manager? But I see your point; treating them like an assembly line takes away the human factor and makes it seem that providing the pair of developers with new requirements and changes would almost seem to imply that they will always get the job done on time.</description>
		<content:encoded><![CDATA[<p>That&#8217;s a good point that you bring up. I can see that happening particularly if the managers themselves haven&#8217;t gone up the chain of ranks from developer to manager. Because our managers can likely also be ITM graduates. It also depends on how the company is structured. Our VP is in direct contact with the developer&#8217;s managers and everything seems to go through him. So the control there is more stringent. The VP is also in direct contact with the clients which is advantageous but, I would say the managers who have a developer background, rather than a business background, would probably be able to better gauge efforts and time frames better. Then the question becomes what makes a good manager? But I see your point; treating them like an assembly line takes away the human factor and makes it seem that providing the pair of developers with new requirements and changes would almost seem to imply that they will always get the job done on time.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: fuzzylizard</title>
		<link>http://www.fuzzylizard.com/archives/2006/12/04/837/comment-page-1/#comment-8073</link>
		<dc:creator>fuzzylizard</dc:creator>
		<pubDate>Wed, 06 Dec 2006 04:23:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.fuzzylizard.com/archives/2006/12/04/837/#comment-8073</guid>
		<description>These are all points that I thought of after I published the blog entry. I guess personal satisfaction comes from working with a smart, intelligent team and from creating software. Although I may not own anyone part of the code, I still own all of the code and the final product that is produced.

One other question that I had that was not mentioned in the article was a fear that doing pair programming can turn a group of developers into  toasters. By this I mean that they are simply viewed as an assembly line for code production and not as individual developers. Or, put a little softer, as a single unit instead of as individual developers with different skills and/or aptitudes. This may be a problem not with pair programming or Agile but with management.</description>
		<content:encoded><![CDATA[<p>These are all points that I thought of after I published the blog entry. I guess personal satisfaction comes from working with a smart, intelligent team and from creating software. Although I may not own anyone part of the code, I still own all of the code and the final product that is produced.</p>
<p>One other question that I had that was not mentioned in the article was a fear that doing pair programming can turn a group of developers into  toasters. By this I mean that they are simply viewed as an assembly line for code production and not as individual developers. Or, put a little softer, as a single unit instead of as individual developers with different skills and/or aptitudes. This may be a problem not with pair programming or Agile but with management.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: I.G.</title>
		<link>http://www.fuzzylizard.com/archives/2006/12/04/837/comment-page-1/#comment-8067</link>
		<dc:creator>I.G.</dc:creator>
		<pubDate>Tue, 05 Dec 2006 13:36:37 +0000</pubDate>
		<guid isPermaLink="false">http://www.fuzzylizard.com/archives/2006/12/04/837/#comment-8067</guid>
		<description>Agile development methodologies are good to have sparingly. Where do you get the satisfaction from? Well hopefully from working with really intelligent people. The company I work for has scrum meetings all the time, however, the actual agile development slacks. We use pair programming sparingly when one developer is stuck on a particular problem that is slowing down the our weekly sprint. We also use a lot of continuous integration via CruiseControl, which makes life very easy. 

If you can&#039;t find the satisfaction in the people you work with then hopefully your project (code) is innovative/simplistic and solves a particular problem which you feel is important. And if that fails, then yes, working on your own pet project should give you some satisfaction. I don&#039;t see the industry adopting agile development methodologies very well at least from what I&#039;ve seen.

Personal satisfaction can also come from using new technologies that are of particular interest to you, ... that is if you are lucky enough to be in that sort of a position.</description>
		<content:encoded><![CDATA[<p>Agile development methodologies are good to have sparingly. Where do you get the satisfaction from? Well hopefully from working with really intelligent people. The company I work for has scrum meetings all the time, however, the actual agile development slacks. We use pair programming sparingly when one developer is stuck on a particular problem that is slowing down the our weekly sprint. We also use a lot of continuous integration via CruiseControl, which makes life very easy. </p>
<p>If you can&#8217;t find the satisfaction in the people you work with then hopefully your project (code) is innovative/simplistic and solves a particular problem which you feel is important. And if that fails, then yes, working on your own pet project should give you some satisfaction. I don&#8217;t see the industry adopting agile development methodologies very well at least from what I&#8217;ve seen.</p>
<p>Personal satisfaction can also come from using new technologies that are of particular interest to you, &#8230; that is if you are lucky enough to be in that sort of a position.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

