<?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: APR: Process Deviation?</title>
	<atom:link href="http://tynerblain.com/blog/2007/05/18/apr-process-deviation/feed/" rel="self" type="application/rss+xml" />
	<link>http://tynerblain.com/blog/2007/05/18/apr-process-deviation/</link>
	<description>Software product success.</description>
	<lastBuildDate>Tue, 22 May 2012 20:46:27 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0.4</generator>
	<item>
		<title>By: Roger L. Cauvin</title>
		<link>http://tynerblain.com/blog/2007/05/18/apr-process-deviation/comment-page-1/#comment-98601</link>
		<dc:creator>Roger L. Cauvin</dc:creator>
		<pubDate>Mon, 21 May 2007 13:29:52 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2007/05/18/apr-process-deviation/#comment-98601</guid>
		<description>That about covers it, Scott :-)  Although there is requirements risk.  Requirements risk comes from not being able to know what users really want until you put something demoable or usable in front of them.  To some extent, the very nature of &lt;a href=&quot;http://cauvin.blogspot.com/2007/05/agile-development.html&quot; rel=&quot;nofollow&quot;&gt;&quot;true&quot; agile&lt;/a&gt; is to confront these risks through frequent releases.

Nonetheless, you might also consider what the biggest requirements unknowns are.  If, for example, security or other nonfunctional requirements were the biggest risk, you would want to implement the use cases (or &lt;a href=&quot;http://cauvin.blogspot.com/2006/12/use-case-versions.html&quot; rel=&quot;nofollow&quot;&gt;use case versions&lt;/a&gt;) that exercise them.</description>
		<content:encoded><![CDATA[<p>That about covers it, Scott :-)  Although there is requirements risk.  Requirements risk comes from not being able to know what users really want until you put something demoable or usable in front of them.  To some extent, the very nature of <a href="http://cauvin.blogspot.com/2007/05/agile-development.html" rel="nofollow">&#8220;true&#8221; agile</a> is to confront these risks through frequent releases.</p>
<p>Nonetheless, you might also consider what the biggest requirements unknowns are.  If, for example, security or other nonfunctional requirements were the biggest risk, you would want to implement the use cases (or <a href="http://cauvin.blogspot.com/2006/12/use-case-versions.html" rel="nofollow">use case versions</a>) that exercise them.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Scott Sehlhorst</title>
		<link>http://tynerblain.com/blog/2007/05/18/apr-process-deviation/comment-page-1/#comment-98350</link>
		<dc:creator>Scott Sehlhorst</dc:creator>
		<pubDate>Sun, 20 May 2007 11:31:37 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2007/05/18/apr-process-deviation/#comment-98350</guid>
		<description>Interesting discussion, and thanks all for the ideas and support!

Exercising risks, or exorcising risks?  The goal is to grow the user base until nexus reaches a tipping point where it becomes more valuable to the contributors than the cost of investing time in the site.  What are the biggest risks to that?

They can be technical, marketing, or functional.  

At the pre-beta stage, I&#039;m not worried about marketing.  Granted, we get a bunch indirectly from readers here, but it isn&#039;t the focus.

Functional risks, I think we will address within the normal use case prioritization exercise, as Rolf suggests.

Technical risks, there are actually a couple - that search work effectively, that we get pagination of the site, that we get emailing set up without becoming a spambot for someone.

Roger - were you thinking of other facets of risk too?</description>
		<content:encoded><![CDATA[<p>Interesting discussion, and thanks all for the ideas and support!</p>
<p>Exercising risks, or exorcising risks?  The goal is to grow the user base until nexus reaches a tipping point where it becomes more valuable to the contributors than the cost of investing time in the site.  What are the biggest risks to that?</p>
<p>They can be technical, marketing, or functional.  </p>
<p>At the pre-beta stage, I&#8217;m not worried about marketing.  Granted, we get a bunch indirectly from readers here, but it isn&#8217;t the focus.</p>
<p>Functional risks, I think we will address within the normal use case prioritization exercise, as Rolf suggests.</p>
<p>Technical risks, there are actually a couple &#8211; that search work effectively, that we get pagination of the site, that we get emailing set up without becoming a spambot for someone.</p>
<p>Roger &#8211; were you thinking of other facets of risk too?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Roger L. Cauvin</title>
		<link>http://tynerblain.com/blog/2007/05/18/apr-process-deviation/comment-page-1/#comment-98212</link>
		<dc:creator>Roger L. Cauvin</dc:creator>
		<pubDate>Sat, 19 May 2007 17:28:14 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2007/05/18/apr-process-deviation/#comment-98212</guid>
		<description>On Rolf&#039;s point about risks versus value: I see the distinction as a false dichotomy.  Failure to deliver value is itself a risk.  When prioritizing risks, you consider all of them, including value and architectural uncertainties.</description>
		<content:encoded><![CDATA[<p>On Rolf&#8217;s point about risks versus value: I see the distinction as a false dichotomy.  Failure to deliver value is itself a risk.  When prioritizing risks, you consider all of them, including value and architectural uncertainties.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Rolf</title>
		<link>http://tynerblain.com/blog/2007/05/18/apr-process-deviation/comment-page-1/#comment-98210</link>
		<dc:creator>Rolf</dc:creator>
		<pubDate>Sat, 19 May 2007 17:21:10 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2007/05/18/apr-process-deviation/#comment-98210</guid>
		<description>&gt;Can I plead temporary insanity?
*lol*

Scott, thank you for your honest analysis. I believe this is how this experiment teaches its audience.
I would agree with Luis, if it was a goal of this experiment to draw scientific conclusions. However, I see it &quot;just&quot; as another chance to get anecdotal evidence on the subject, which might lead to some theory in the future. Over all, I&#039;m happy with it.

I tend to follow Rogers idea of exercising risks, that&#039;s kind of what I used to do in my projects. But some really cool article on the web - which I don&#039;t recognise anymore, sh** - suggested to design value in instead of designing risks out. So I propose going over the use cases, see what we can change or add, do a quick round on priorities and off we go. 

PS: Please let me add another quick remark on the term prototype, which somehow made it into our APR language. I think there&#039;s not much room for prototypes in agile development (there is room, but it is almost before the start). The Nexus alpha release is exactly that: a release.

PPS: the cool thing about wearing lots of hats is that you can gain different kinds of satisfaction. It adds up! :-) Keep motivated, Scott.</description>
		<content:encoded><![CDATA[<p>&gt;Can I plead temporary insanity?<br />
*lol*</p>
<p>Scott, thank you for your honest analysis. I believe this is how this experiment teaches its audience.<br />
I would agree with Luis, if it was a goal of this experiment to draw scientific conclusions. However, I see it &#8220;just&#8221; as another chance to get anecdotal evidence on the subject, which might lead to some theory in the future. Over all, I&#8217;m happy with it.</p>
<p>I tend to follow Rogers idea of exercising risks, that&#8217;s kind of what I used to do in my projects. But some really cool article on the web &#8211; which I don&#8217;t recognise anymore, sh** &#8211; suggested to design value in instead of designing risks out. So I propose going over the use cases, see what we can change or add, do a quick round on priorities and off we go. </p>
<p>PS: Please let me add another quick remark on the term prototype, which somehow made it into our APR language. I think there&#8217;s not much room for prototypes in agile development (there is room, but it is almost before the start). The Nexus alpha release is exactly that: a release.</p>
<p>PPS: the cool thing about wearing lots of hats is that you can gain different kinds of satisfaction. It adds up! :-) Keep motivated, Scott.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Luis Sergio Oliveira</title>
		<link>http://tynerblain.com/blog/2007/05/18/apr-process-deviation/comment-page-1/#comment-98171</link>
		<dc:creator>Luis Sergio Oliveira</dc:creator>
		<pubDate>Sat, 19 May 2007 14:09:56 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2007/05/18/apr-process-deviation/#comment-98171</guid>
		<description>IMO you are wearing too much hats to hope any approximately scientific conclusion out of this experiment.
But, being so, this allows you to decide faster and drive the implementation of the idea and vision you have in your head faster and in a much more agile way than common agile projects.

So, I would say you should continue the way you were during the first iteration.</description>
		<content:encoded><![CDATA[<p>IMO you are wearing too much hats to hope any approximately scientific conclusion out of this experiment.<br />
But, being so, this allows you to decide faster and drive the implementation of the idea and vision you have in your head faster and in a much more agile way than common agile projects.</p>
<p>So, I would say you should continue the way you were during the first iteration.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Roger L. Cauvin</title>
		<link>http://tynerblain.com/blog/2007/05/18/apr-process-deviation/comment-page-1/#comment-98000</link>
		<dc:creator>Roger L. Cauvin</dc:creator>
		<pubDate>Fri, 18 May 2007 23:31:35 +0000</pubDate>
		<guid isPermaLink="false">http://tynerblain.com/blog/2007/05/18/apr-process-deviation/#comment-98000</guid>
		<description>As an answer to your quesiton of what you should do in the next release, I would think of what the biggest risk you face at this point in the project.  Then I would find the quickest way to release a version of the product that exercises the risk.</description>
		<content:encoded><![CDATA[<p>As an answer to your quesiton of what you should do in the next release, I would think of what the biggest risk you face at this point in the project.  Then I would find the quickest way to release a version of the product that exercises the risk.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

