<?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 for Core group</title>
	<atom:link href="http://www.coregroup.no/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.coregroup.no</link>
	<description>Vi arbeider med kommersialisering og transformasjon av IT-, telecom- og mediabedrifter.</description>
	<lastBuildDate>Tue, 21 Feb 2012 20:10:52 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>Comment on When Scrum fails by Niklas Bjørnerstedt</title>
		<link>http://www.coregroup.no/2012/02/when-scrum-fails/comment-page-1/#comment-10404</link>
		<dc:creator>Niklas Bjørnerstedt</dc:creator>
		<pubDate>Tue, 21 Feb 2012 20:10:52 +0000</pubDate>
		<guid isPermaLink="false">http://www.coregroup.no/?p=1442#comment-10404</guid>
		<description>Geir,

Actually, there were multiple product owners on the valiant Scrum master project. Since I was not part of the project I cannot say whether this particular product owner did a good job. I find it interesting that you are so certain that the cause of the problems was a poor scrum implementation. It is dangerously close to the &quot;if you get sick your faith is not strong enough&quot; argument. Suppose the product owner had taken this problem up in a retrospective. The result might then have been a team that was forced to abandon most sprints. It is not always possible to eliminate the root causes of disturbances. 

Some of the remedies to this kind of problem that I&#039;ve heard in Scrum circles are based on ever more planning. That is not a road I am comfortable with.

PS Spell my name right next time... :)</description>
		<content:encoded><![CDATA[<p>Geir,</p>
<p>Actually, there were multiple product owners on the valiant Scrum master project. Since I was not part of the project I cannot say whether this particular product owner did a good job. I find it interesting that you are so certain that the cause of the problems was a poor scrum implementation. It is dangerously close to the &#8220;if you get sick your faith is not strong enough&#8221; argument. Suppose the product owner had taken this problem up in a retrospective. The result might then have been a team that was forced to abandon most sprints. It is not always possible to eliminate the root causes of disturbances. </p>
<p>Some of the remedies to this kind of problem that I&#8217;ve heard in Scrum circles are based on ever more planning. That is not a road I am comfortable with.</p>
<p>PS Spell my name right next time&#8230; <img src='http://www.coregroup.no/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on When Scrum fails by Geir Amsjø</title>
		<link>http://www.coregroup.no/2012/02/when-scrum-fails/comment-page-1/#comment-10403</link>
		<dc:creator>Geir Amsjø</dc:creator>
		<pubDate>Tue, 21 Feb 2012 15:46:03 +0000</pubDate>
		<guid isPermaLink="false">http://www.coregroup.no/?p=1442#comment-10403</guid>
		<description>Hi Nicolas,
David Anderson like to tell &quot;Scrum stinks, Kanban is the way&quot; stories. That is fine, but it is interesting that the examples he uses describes a bad Scrum implementation. The same goes for your story with the valiant Scrum Master. In the story there is no Product Owner, and that is probably the reason why the Scrum Master was allowed to continue with his eager team shielding practice. The Scrum Master is supposed to shield the development team &lt;i&gt;if necessary&lt;/i&gt;. A good product owner would never allowed this bad, sub-optimal behavior to continue without bringing it up as a major problem in a retrospective.</description>
		<content:encoded><![CDATA[<p>Hi Nicolas,<br />
David Anderson like to tell &#8220;Scrum stinks, Kanban is the way&#8221; stories. That is fine, but it is interesting that the examples he uses describes a bad Scrum implementation. The same goes for your story with the valiant Scrum Master. In the story there is no Product Owner, and that is probably the reason why the Scrum Master was allowed to continue with his eager team shielding practice. The Scrum Master is supposed to shield the development team <i>if necessary</i>. A good product owner would never allowed this bad, sub-optimal behavior to continue without bringing it up as a major problem in a retrospective.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on When Scrum fails by Niklas Bjørnerstedt</title>
		<link>http://www.coregroup.no/2012/02/when-scrum-fails/comment-page-1/#comment-10396</link>
		<dc:creator>Niklas Bjørnerstedt</dc:creator>
		<pubDate>Tue, 07 Feb 2012 20:19:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.coregroup.no/?p=1442#comment-10396</guid>
		<description>Hi Dagfinn,
I am aware of that possibility, it is just that it was not relevant in the case I was involved with. It was an organization that has hundreds of developers and scores of ongoing projects. These projects often involve large parts of the organization to some degree. Add to that the fact that my mandate was to help a few of these teams, not the whole organization. It would have been quixotic for me to set the goal of changing the environment. Most scrum &quot;remove the impediments&quot; stories are really about big projects, not big organizations where the actions of one project often have unintended consequences for other projects. A scrum of scrums is not a good solution in this kind of environment. 
The case David Anderson talked about in the Meetup is also a situation where you just have to accept your environment. A startup is a startup.</description>
		<content:encoded><![CDATA[<p>Hi Dagfinn,<br />
I am aware of that possibility, it is just that it was not relevant in the case I was involved with. It was an organization that has hundreds of developers and scores of ongoing projects. These projects often involve large parts of the organization to some degree. Add to that the fact that my mandate was to help a few of these teams, not the whole organization. It would have been quixotic for me to set the goal of changing the environment. Most scrum &#8220;remove the impediments&#8221; stories are really about big projects, not big organizations where the actions of one project often have unintended consequences for other projects. A scrum of scrums is not a good solution in this kind of environment.<br />
The case David Anderson talked about in the Meetup is also a situation where you just have to accept your environment. A startup is a startup.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on When Scrum fails by Dagfinn Reiersøl</title>
		<link>http://www.coregroup.no/2012/02/when-scrum-fails/comment-page-1/#comment-10395</link>
		<dc:creator>Dagfinn Reiersøl</dc:creator>
		<pubDate>Tue, 07 Feb 2012 18:21:58 +0000</pubDate>
		<guid isPermaLink="false">http://www.coregroup.no/?p=1442#comment-10395</guid>
		<description>Ken Schwaber says (I&#039;m paraphrasing): Scrum doesn&#039;t solve your problems, it only exposes them. So my question is, when you abandon Scrum because it you can&#039;t get it to work properly, are you doing the only right thing, or are you just avoiding dealing with the impediment that Scrum has exposed?

If the environment is chaotic and interdependent, do you really need to use a Kanban based approach, or would you be better off changing the environment, if possible. Is chaos and interdependence caused by poor code quality, insufficient training and other variables that should addressed? And could Kanban be just what you need to stay mediocre in those areas? I think the answer is yes -- sometimes. But my experience is insufficiently varied to generalize about it, so I&#039;m just pointing out the possibility.</description>
		<content:encoded><![CDATA[<p>Ken Schwaber says (I&#8217;m paraphrasing): Scrum doesn&#8217;t solve your problems, it only exposes them. So my question is, when you abandon Scrum because it you can&#8217;t get it to work properly, are you doing the only right thing, or are you just avoiding dealing with the impediment that Scrum has exposed?</p>
<p>If the environment is chaotic and interdependent, do you really need to use a Kanban based approach, or would you be better off changing the environment, if possible. Is chaos and interdependence caused by poor code quality, insufficient training and other variables that should addressed? And could Kanban be just what you need to stay mediocre in those areas? I think the answer is yes &#8212; sometimes. But my experience is insufficiently varied to generalize about it, so I&#8217;m just pointing out the possibility.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

