<?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: The Kanban Story: Pseudo Iterations</title>
	<atom:link href="http://blog.brodzinski.com/2010/01/kanban-iterations.html/feed" rel="self" type="application/rss+xml" />
	<link>http://blog.brodzinski.com/2010/01/kanban-iterations.html</link>
	<description>Dealing with software projects in real life</description>
	<lastBuildDate>Thu, 29 Jul 2010 10:46:22 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
	<item>
		<title>By: Pawel Brodzinski</title>
		<link>http://blog.brodzinski.com/2010/01/kanban-iterations.html#comment-3027</link>
		<dc:creator>Pawel Brodzinski</dc:creator>
		<pubDate>Fri, 22 Jan 2010 09:22:49 +0000</pubDate>
		<guid isPermaLink="false">http://blog.brodzinski.com/?p=1541#comment-3027</guid>
		<description>Estimation is generally tricky. For a developer it is additional task which doesn&#039;t add a value. The more detailed estimation you do the more time you have to spend on this.

On the other hand for a PM, or generally for management, estimation is often invaluable. Take a customer who doesn&#039;t want to follow agile development - they just want to know what they&#039;re going to get and when. Sure you can have agile process implemented internally but you still sell a project for a customer the old-school way thus estimation is inevitable. The same situation happens when sales folks need to know how much they have to charge client for a project.

By the way the same problem is with time tracking. From developer&#039;s point of view it is a waste of time. For management this is very important information.</description>
		<content:encoded><![CDATA[<p>Estimation is generally tricky. For a developer it is additional task which doesn&#8217;t add a value. The more detailed estimation you do the more time you have to spend on this.</p>
<p>On the other hand for a PM, or generally for management, estimation is often invaluable. Take a customer who doesn&#8217;t want to follow agile development &#8211; they just want to know what they&#8217;re going to get and when. Sure you can have agile process implemented internally but you still sell a project for a customer the old-school way thus estimation is inevitable. The same situation happens when sales folks need to know how much they have to charge client for a project.</p>
<p>By the way the same problem is with time tracking. From developer&#8217;s point of view it is a waste of time. For management this is very important information.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Vukoje</title>
		<link>http://blog.brodzinski.com/2010/01/kanban-iterations.html#comment-3025</link>
		<dc:creator>Vukoje</dc:creator>
		<pubDate>Fri, 22 Jan 2010 09:00:56 +0000</pubDate>
		<guid isPermaLink="false">http://blog.brodzinski.com/?p=1541#comment-3025</guid>
		<description>I personally always wanted to avoid task estimations because I could never get it right and it consumed time to estimate issue. So it seamed as pure waist.  

Off course, over time I found out all hidden benefits of estimations, even the wrong ones. 

Here are my thoughts on Scrum after completing the course, maybe it can be useful or you may help with your point of view.
 http://vukoje.net/post/2009/07/21/Things-learned-at-Scrum-Master-training.aspx</description>
		<content:encoded><![CDATA[<p>I personally always wanted to avoid task estimations because I could never get it right and it consumed time to estimate issue. So it seamed as pure waist.  </p>
<p>Off course, over time I found out all hidden benefits of estimations, even the wrong ones. </p>
<p>Here are my thoughts on Scrum after completing the course, maybe it can be useful or you may help with your point of view.<br />
 <a href="http://vukoje.net/post/2009/07/21/Things-learned-at-Scrum-Master-training.aspx" rel="nofollow">http://vukoje.net/post/2009/07/21/Things-learned-at-Scrum-Master-training.aspx</a></p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Pawel Brodzinski</title>
		<link>http://blog.brodzinski.com/2010/01/kanban-iterations.html#comment-2949</link>
		<dc:creator>Pawel Brodzinski</dc:creator>
		<pubDate>Wed, 20 Jan 2010 08:47:06 +0000</pubDate>
		<guid isPermaLink="false">http://blog.brodzinski.com/?p=1541#comment-2949</guid>
		<description>I&#039;m waiting to see what we&#039;re going to end up with too.

Very insightful remark about Scrum. I don&#039;t think however this is the case.

First, I never rejected Scrum because it seemed hard. I&#039;ve rejected it because in a few places we it would bring us much trouble, time-boxing being the most significant one.

Second, I never stated I don&#039;t like Scrum or won&#039;t use its techniques. We employed some of them before we even started with Kanban.

Third, I don&#039;t think our we could be called a Scrum team. I think we&#039;re pretty far from that. Even if we have kind of iterations we still don&#039;t use time-boxing. Definition of our iteration is &quot;contains few MMFs&quot; not &quot;takes two weeks&quot; which is an important difference.

The other thing is how much you can change methodology and still call it the old name, but to be honest - I don&#039;t care. No matter you call it modified Scrum, Kanban or whatever, if it works for me that&#039;s great.

By the way: thanks for this comment. Food for thought.</description>
		<content:encoded><![CDATA[<p>I&#8217;m waiting to see what we&#8217;re going to end up with too.</p>
<p>Very insightful remark about Scrum. I don&#8217;t think however this is the case.</p>
<p>First, I never rejected Scrum because it seemed hard. I&#8217;ve rejected it because in a few places we it would bring us much trouble, time-boxing being the most significant one.</p>
<p>Second, I never stated I don&#8217;t like Scrum or won&#8217;t use its techniques. We employed some of them before we even started with Kanban.</p>
<p>Third, I don&#8217;t think our we could be called a Scrum team. I think we&#8217;re pretty far from that. Even if we have kind of iterations we still don&#8217;t use time-boxing. Definition of our iteration is &#8220;contains few MMFs&#8221; not &#8220;takes two weeks&#8221; which is an important difference.</p>
<p>The other thing is how much you can change methodology and still call it the old name, but to be honest &#8211; I don&#8217;t care. No matter you call it modified Scrum, Kanban or whatever, if it works for me that&#8217;s great.</p>
<p>By the way: thanks for this comment. Food for thought.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Vukoje</title>
		<link>http://blog.brodzinski.com/2010/01/kanban-iterations.html#comment-2942</link>
		<dc:creator>Vukoje</dc:creator>
		<pubDate>Tue, 19 Jan 2010 22:30:04 +0000</pubDate>
		<guid isPermaLink="false">http://blog.brodzinski.com/?p=1541#comment-2942</guid>
		<description>I am following your Kanban story from the start and I&#039;m waiting to see how it will turn out for you.

Still, I can&#039;t resist the filling that you will end up with modified Scrum, wondering if rules you have avoided were hurting your real life agility or you just avoided them because they seamed hard. I know I do wonder for my Scrum adaptation.</description>
		<content:encoded><![CDATA[<p>I am following your Kanban story from the start and I&#8217;m waiting to see how it will turn out for you.</p>
<p>Still, I can&#8217;t resist the filling that you will end up with modified Scrum, wondering if rules you have avoided were hurting your real life agility or you just avoided them because they seamed hard. I know I do wonder for my Scrum adaptation.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
