<?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: My inferences about Agile from Sanjiv Augustine&#8217;s workshop at Xebia India</title>
	<atom:link href="http://blog.xebia.com/2008/11/21/my-inferences-about-agile-from-sanjiv-augustines-workshop-at-xebia-india/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.xebia.com/2008/11/21/my-inferences-about-agile-from-sanjiv-augustines-workshop-at-xebia-india/</link>
	<description>Software development done right!</description>
	<lastBuildDate>Wed, 08 Feb 2012 14:41:38 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Serge Beaumont</title>
		<link>http://blog.xebia.com/2008/11/21/my-inferences-about-agile-from-sanjiv-augustines-workshop-at-xebia-india/#comment-63828</link>
		<dc:creator>Serge Beaumont</dc:creator>
		<pubDate>Sun, 23 Nov 2008 09:08:06 +0000</pubDate>
		<guid isPermaLink="false">http://blog.xebia.com/?p=817#comment-63828</guid>
		<description>@Josh: I rephrase the WBS part. A backlog is a list of outcomes, not work. So it is a Product Breakdown Structure, not a WBS. One of the traps of planning based on activity is the belief that executing all activities will automatically achieve the end results. Of course this is not the case, and everybody should have the outcome in mind at all times. This is what allows a team to identify the need for different work than was originally planned to reach the outcome.</description>
		<content:encoded><![CDATA[<p>@Josh: I rephrase the WBS part. A backlog is a list of outcomes, not work. So it is a Product Breakdown Structure, not a WBS. One of the traps of planning based on activity is the belief that executing all activities will automatically achieve the end results. Of course this is not the case, and everybody should have the outcome in mind at all times. This is what allows a team to identify the need for different work than was originally planned to reach the outcome.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Anurag Shrivastava</title>
		<link>http://blog.xebia.com/2008/11/21/my-inferences-about-agile-from-sanjiv-augustines-workshop-at-xebia-india/#comment-63799</link>
		<dc:creator>Anurag Shrivastava</dc:creator>
		<pubDate>Sun, 23 Nov 2008 06:47:53 +0000</pubDate>
		<guid isPermaLink="false">http://blog.xebia.com/?p=817#comment-63799</guid>
		<description>&quot;The fact that Agile is built on passion, transparency, trust, discipline, liberty, opportunity, reciprocity and equality helps in creating a great and highly productive working environment.&quot; 

Many people ask how they can build an Agile team in a company. Passion,....,equality are the first things to be looked at. Teams may falter at times.  Managers should play a crucial role in keeping the Agile spirit alive.</description>
		<content:encoded><![CDATA[<p>&#8220;The fact that Agile is built on passion, transparency, trust, discipline, liberty, opportunity, reciprocity and equality helps in creating a great and highly productive working environment.&#8221; </p>
<p>Many people ask how they can build an Agile team in a company. Passion,&#8230;.,equality are the first things to be looked at. Teams may falter at times.  Managers should play a crucial role in keeping the Agile spirit alive.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Abhinav Kumar</title>
		<link>http://blog.xebia.com/2008/11/21/my-inferences-about-agile-from-sanjiv-augustines-workshop-at-xebia-india/#comment-63723</link>
		<dc:creator>Abhinav Kumar</dc:creator>
		<pubDate>Sat, 22 Nov 2008 18:35:13 +0000</pubDate>
		<guid isPermaLink="false">http://blog.xebia.com/?p=817#comment-63723</guid>
		<description>Thanks for reading the post and adding your invaluable comments. It is immaculate. I could not have agreed more. Perhaps I could have been more explicit by saying that plan the work ONCE and work that plan FOREVER is not the way to go anymore. And thanks for showing the way to go in no implicit terms.</description>
		<content:encoded><![CDATA[<p>Thanks for reading the post and adding your invaluable comments. It is immaculate. I could not have agreed more. Perhaps I could have been more explicit by saying that plan the work ONCE and work that plan FOREVER is not the way to go anymore. And thanks for showing the way to go in no implicit terms.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Josh Nankivel</title>
		<link>http://blog.xebia.com/2008/11/21/my-inferences-about-agile-from-sanjiv-augustines-workshop-at-xebia-india/#comment-63649</link>
		<dc:creator>Josh Nankivel</dc:creator>
		<pubDate>Sat, 22 Nov 2008 11:36:06 +0000</pubDate>
		<guid isPermaLink="false">http://blog.xebia.com/?p=817#comment-63649</guid>
		<description>Thanks for the post.  I just wanted to add a little more to your comments about the planning that is still required with Agile.  This is what I have used in the past and have found works well.  The moral of the story is that you don&#039;t get away with less planning when you do Agile right, in my opinion.  You are just spreading out your planning across the sprints, and so you have more information with each one...and your planning gets better and better.  You STILL plan the work, and work the plan.

1) Develop a high-level plan up front.  This is much less rigorous than traditional waterfall planning, but gives you a high-level WBS structure, major deliverables/list of features, engineering approach, architecture, etc.  You plan how many sprints the project should take and roughly how many features will get developed each sprint.
2) Plan each sprint in detail regarding the features that will be developed, and stick to that plan for the duration of the sprint.
3) After each sprint review, you have better information to adjust the high-level project plan, and make the next sprint plan more accurate.

Josh Nankivel
http://pmStudent.com</description>
		<content:encoded><![CDATA[<p>Thanks for the post.  I just wanted to add a little more to your comments about the planning that is still required with Agile.  This is what I have used in the past and have found works well.  The moral of the story is that you don&#8217;t get away with less planning when you do Agile right, in my opinion.  You are just spreading out your planning across the sprints, and so you have more information with each one&#8230;and your planning gets better and better.  You STILL plan the work, and work the plan.</p>
<p>1) Develop a high-level plan up front.  This is much less rigorous than traditional waterfall planning, but gives you a high-level WBS structure, major deliverables/list of features, engineering approach, architecture, etc.  You plan how many sprints the project should take and roughly how many features will get developed each sprint.<br />
2) Plan each sprint in detail regarding the features that will be developed, and stick to that plan for the duration of the sprint.<br />
3) After each sprint review, you have better information to adjust the high-level project plan, and make the next sprint plan more accurate.</p>
<p>Josh Nankivel<br />
<a href="http://pmStudent.com" rel="nofollow">http://pmStudent.com</a></p>
]]></content:encoded>
	</item>
</channel>
</rss>
<!-- This Quick Cache file was built for (  blog.xebia.com/2008/11/21/my-inferences-about-agile-from-sanjiv-augustines-workshop-at-xebia-india/feed/ ) in 0.51225 seconds, on Feb 9th, 2012 at 10:19 pm UTC. -->
<!-- This Quick Cache file will automatically expire ( and be re-built automatically ) on Feb 9th, 2012 at 11:19 pm UTC -->
