<?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: Definition of Agile Development</title>
	<atom:link href="http://www.agilekiwi.com/other/agile/definition-of-agile-development/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.agilekiwi.com/other/agile/definition-of-agile-development/</link>
	<description>The neglected essentials of software development</description>
	<lastBuildDate>Fri, 03 Feb 2012 07:28:23 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.2.1</generator>
	<item>
		<title>By: Gebhard Greiter</title>
		<link>http://www.agilekiwi.com/other/agile/definition-of-agile-development/comment-page-1/#comment-568</link>
		<dc:creator>Gebhard Greiter</dc:creator>
		<pubDate>Sat, 28 Jan 2012 07:49:04 +0000</pubDate>
		<guid isPermaLink="false">http://dell-pc/AgileKiwiWordpress/?p=46#comment-568</guid>
		<description>You may want to read &lt;a href=&quot;http://ggreiter.wordpress.com/2012/01/23/against-misunderstandig-agile/&quot; / rel=&quot;nofollow&quot;&gt;Against misunderstanding Agile&lt;/a&gt;.</description>
		<content:encoded><![CDATA[<p>You may want to read <a href="http://ggreiter.wordpress.com/2012/01/23/against-misunderstandig-agile/" / rel="nofollow">Against misunderstanding Agile</a>.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Gebhard Greiter</title>
		<link>http://www.agilekiwi.com/other/agile/definition-of-agile-development/comment-page-1/#comment-523</link>
		<dc:creator>Gebhard Greiter</dc:creator>
		<pubDate>Sun, 16 Oct 2011 06:32:01 +0000</pubDate>
		<guid isPermaLink="false">http://dell-pc/AgileKiwiWordpress/?p=46#comment-523</guid>
		<description>Please read also: &lt;a href=&quot;http://greiterweb.de/spw/dox/The_New_(2011)_Definitions_of_Agile.pdf&quot; rel=&quot;nofollow&quot;&gt;The New (2011) Definitions of Agile&lt;/a&gt;.</description>
		<content:encoded><![CDATA[<p>Please read also: <a href="http://greiterweb.de/spw/dox/The_New_(2011)_Definitions_of_Agile.pdf" rel="nofollow">The New (2011) Definitions of Agile</a>.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Gebhard Greiter</title>
		<link>http://www.agilekiwi.com/other/agile/definition-of-agile-development/comment-page-1/#comment-522</link>
		<dc:creator>Gebhard Greiter</dc:creator>
		<pubDate>Wed, 12 Oct 2011 17:36:55 +0000</pubDate>
		<guid isPermaLink="false">http://dell-pc/AgileKiwiWordpress/?p=46#comment-522</guid>
		<description>So far we only learned that being agile has become necessary. &lt;b&gt;The best way to agility however has still to be found&lt;/b&gt;. 

My definition of Agile is twofold:

&lt;b&gt;Software Developer&#039;s Definition of Agile:&lt;/b&gt;

Agility means to have a process in place that will allow us (and urge us)
to react on changing business requirements as soon as possible:
Accept that the project’s goal is a moving target.

&lt;b&gt;Project Manager&#039;s Definition of Agile:&lt;/b&gt;

Agile Project Management means to have a process in place
that is to maximize team efficiency.



You may want to read 
&lt;a href=&quot;http://www.greiterweb.de/spw/Agile_is_not_Manifesto.htm&quot; rel=&quot;nofollow&quot;&gt;Agility is fine – the Manifesto can be Poison&lt;/a&gt;.</description>
		<content:encoded><![CDATA[<p>So far we only learned that being agile has become necessary. <b>The best way to agility however has still to be found</b>. </p>
<p>My definition of Agile is twofold:</p>
<p><b>Software Developer&#8217;s Definition of Agile:</b></p>
<p>Agility means to have a process in place that will allow us (and urge us)<br />
to react on changing business requirements as soon as possible:<br />
Accept that the project’s goal is a moving target.</p>
<p><b>Project Manager&#8217;s Definition of Agile:</b></p>
<p>Agile Project Management means to have a process in place<br />
that is to maximize team efficiency.</p>
<p>You may want to read<br />
<a href="http://www.greiterweb.de/spw/Agile_is_not_Manifesto.htm" rel="nofollow">Agility is fine – the Manifesto can be Poison</a>.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: cbemerine</title>
		<link>http://www.agilekiwi.com/other/agile/definition-of-agile-development/comment-page-1/#comment-501</link>
		<dc:creator>cbemerine</dc:creator>
		<pubDate>Fri, 19 Aug 2011 20:21:01 +0000</pubDate>
		<guid isPermaLink="false">http://dell-pc/AgileKiwiWordpress/?p=46#comment-501</guid>
		<description>While improving my PHP coding skills, I have been looking for tools to help me become a better programmer, estimator, a more productive member of any team.

The further down the agile rabbit hole I travel, the more obvious it becomes, successful groups have one thing in common.  The company, the management team, the group all focus on &quot;people&quot; first and those programmers select the tools/processes that work for their team. 

As long as the group can reach a sustainable velocity, that never results in a death march, enabling them to deliver &quot;done done&quot; end user solutions in a repeatable way...does the process they use truly matter?  [Assume members can be swapped in/out, code is not refractored beyond a state of understanding nor is it sloppy as that would seriously impact future velocity in maintenance.]

When the agile (little a) group choses the tools and processes, they will be more effective than a group that has tools/processes thrust upon them. Its a subtle yet very important difference that often makes the difference between success and failure.  (i.e. Are your stories assigned or selected?, that subtle)

Perhaps TDD will be the best, perhaps XP, perhaps some hybrid of those with a little something spicy thrown in will work better.  Whatever the end recipe, tools, processes, intelligent management gets out of the way to avoid killing the groups creativity and inventiveness, at least if they are truly &quot;smart&quot; they do.

When in a management position, my team members always came first and we delivered.  My experience in teams and business units where the processes were dictated by others, not selected by the group, we often had difficulty delivering completed products on time and on schedule, without a death march.  We were often micro-managed and the processes were onerous...programmer turnover was high.

The concept of putting people first is hardly a new one, just reference Wideband Delphi, developed in the 1940s.  And agile makes estimating effective with the ability to reach a sustainable velocity in as few as three or four iterations.

Your definition focuses on people first, without regards to any specific process or tool, that makes it a good definition.</description>
		<content:encoded><![CDATA[<p>While improving my PHP coding skills, I have been looking for tools to help me become a better programmer, estimator, a more productive member of any team.</p>
<p>The further down the agile rabbit hole I travel, the more obvious it becomes, successful groups have one thing in common.  The company, the management team, the group all focus on &#8220;people&#8221; first and those programmers select the tools/processes that work for their team. </p>
<p>As long as the group can reach a sustainable velocity, that never results in a death march, enabling them to deliver &#8220;done done&#8221; end user solutions in a repeatable way&#8230;does the process they use truly matter?  [Assume members can be swapped in/out, code is not refractored beyond a state of understanding nor is it sloppy as that would seriously impact future velocity in maintenance.]</p>
<p>When the agile (little a) group choses the tools and processes, they will be more effective than a group that has tools/processes thrust upon them. Its a subtle yet very important difference that often makes the difference between success and failure.  (i.e. Are your stories assigned or selected?, that subtle)</p>
<p>Perhaps TDD will be the best, perhaps XP, perhaps some hybrid of those with a little something spicy thrown in will work better.  Whatever the end recipe, tools, processes, intelligent management gets out of the way to avoid killing the groups creativity and inventiveness, at least if they are truly &#8220;smart&#8221; they do.</p>
<p>When in a management position, my team members always came first and we delivered.  My experience in teams and business units where the processes were dictated by others, not selected by the group, we often had difficulty delivering completed products on time and on schedule, without a death march.  We were often micro-managed and the processes were onerous&#8230;programmer turnover was high.</p>
<p>The concept of putting people first is hardly a new one, just reference Wideband Delphi, developed in the 1940s.  And agile makes estimating effective with the ability to reach a sustainable velocity in as few as three or four iterations.</p>
<p>Your definition focuses on people first, without regards to any specific process or tool, that makes it a good definition.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Malik Shahzad</title>
		<link>http://www.agilekiwi.com/other/agile/definition-of-agile-development/comment-page-1/#comment-384</link>
		<dc:creator>Malik Shahzad</dc:creator>
		<pubDate>Sun, 05 Jun 2011 15:14:44 +0000</pubDate>
		<guid isPermaLink="false">http://dell-pc/AgileKiwiWordpress/?p=46#comment-384</guid>
		<description>Really nice, and helpful..!</description>
		<content:encoded><![CDATA[<p>Really nice, and helpful..!</p>
]]></content:encoded>
	</item>
</channel>
</rss>

