<?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 Agile Business Analyst is an Oxymoron</title>
	<atom:link href="http://decision-coach.com/the-agile-business-analyst-is-an-oxymoron/feed/" rel="self" type="application/rss+xml" />
	<link>http://decision-coach.com/the-agile-business-analyst-is-an-oxymoron/</link>
	<description>Decisions, commitments, options: why are they so hard?</description>
	<lastBuildDate>Mon, 24 Oct 2011 22:20:46 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Agile or Waterfall</title>
		<link>http://decision-coach.com/the-agile-business-analyst-is-an-oxymoron/comment-page-1/#comment-1147</link>
		<dc:creator>Agile or Waterfall</dc:creator>
		<pubDate>Sun, 03 Jul 2011 10:02:45 +0000</pubDate>
		<guid isPermaLink="false">http://decision-coach.com/?p=215#comment-1147</guid>
		<description>I think that the problem is not that there is a Business Analyst Role, the problem is rather than when there is it is often fulfilled by a clueless consultant (in France companies tend to recruit anybody without any real experience) with/without often a clueless project manager (who just knows PPT and Microsoft Project) or by a User who doesn&#039;t understand that developers need elicitation. So I rarely let users discuss with developers directly because it very often lead to nasty fights and project failure. Nevertheless I&#039;m not against developers being present at Business Meeting but they do not lead the discussion.</description>
		<content:encoded><![CDATA[<p>I think that the problem is not that there is a Business Analyst Role, the problem is rather than when there is it is often fulfilled by a clueless consultant (in France companies tend to recruit anybody without any real experience) with/without often a clueless project manager (who just knows PPT and Microsoft Project) or by a User who doesn&#8217;t understand that developers need elicitation. So I rarely let users discuss with developers directly because it very often lead to nasty fights and project failure. Nevertheless I&#8217;m not against developers being present at Business Meeting but they do not lead the discussion.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Software Is Just A Means To An End &#124; The Agile Pirate</title>
		<link>http://decision-coach.com/the-agile-business-analyst-is-an-oxymoron/comment-page-1/#comment-1141</link>
		<dc:creator>Software Is Just A Means To An End &#124; The Agile Pirate</dc:creator>
		<pubDate>Wed, 16 Mar 2011 21:07:47 +0000</pubDate>
		<guid isPermaLink="false">http://decision-coach.com/?p=215#comment-1141</guid>
		<description>[...] Means To An End  Posted on March 15, 2011 by The Dread Pirate Crom     Last year Chris Matts wrote an insightful post reflecting on the Agile Manifesto and business analysis. At the time it sparked some creative [...]</description>
		<content:encoded><![CDATA[<p>[...] Means To An End  Posted on March 15, 2011 by The Dread Pirate Crom     Last year Chris Matts wrote an insightful post reflecting on the Agile Manifesto and business analysis. At the time it sparked some creative [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Achille Carette</title>
		<link>http://decision-coach.com/the-agile-business-analyst-is-an-oxymoron/comment-page-1/#comment-1135</link>
		<dc:creator>Achille Carette</dc:creator>
		<pubDate>Mon, 17 Jan 2011 13:10:46 +0000</pubDate>
		<guid isPermaLink="false">http://decision-coach.com/?p=215#comment-1135</guid>
		<description>Agile business analyst is not an oxymoron at all (but, as you said, it is a question of definition)

According to my experience, agile has its value but also has its limits. Even if &quot;extended documentation&quot; is not best way to go, &quot;some&quot; documentation is useful. I found necessary to have someone formalizing what is discussed between the developers and the business representatives.

I also asked a similar question on my blog: is velocity agile ? (http://achillecarette.blogspot.com/2008/12/is-velocity-agile.html)</description>
		<content:encoded><![CDATA[<p>Agile business analyst is not an oxymoron at all (but, as you said, it is a question of definition)</p>
<p>According to my experience, agile has its value but also has its limits. Even if &#8220;extended documentation&#8221; is not best way to go, &#8220;some&#8221; documentation is useful. I found necessary to have someone formalizing what is discussed between the developers and the business representatives.</p>
<p>I also asked a similar question on my blog: is velocity agile ? (<a href="http://achillecarette.blogspot.com/2008/12/is-velocity-agile.html" rel="nofollow">http://achillecarette.blogspot.com/2008/12/is-velocity-agile.html</a>)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: J. B. Rainsberger</title>
		<link>http://decision-coach.com/the-agile-business-analyst-is-an-oxymoron/comment-page-1/#comment-1134</link>
		<dc:creator>J. B. Rainsberger</dc:creator>
		<pubDate>Fri, 27 Aug 2010 16:10:49 +0000</pubDate>
		<guid isPermaLink="false">http://decision-coach.com/?p=215#comment-1134</guid>
		<description>I don&#039;t like the phrase &quot;deliver business value&quot;, as we cannot do that alone. We can enable our customers to deliver business value for themselves, and we can deliver business value for ourselves, but can&#039;t deliver business value /for them/, which I believe most people mean by that phrase.

Discuss.

Oh, yes. Your bit. I agree: if a business analyst acts as an agent of the customer, helping her refine vague business goals and identify smaller, more valuable subfeatures, then I find on oxymoron in &quot;agile business analyst&quot;.</description>
		<content:encoded><![CDATA[<p>I don&#8217;t like the phrase &#8220;deliver business value&#8221;, as we cannot do that alone. We can enable our customers to deliver business value for themselves, and we can deliver business value for ourselves, but can&#8217;t deliver business value /for them/, which I believe most people mean by that phrase.</p>
<p>Discuss.</p>
<p>Oh, yes. Your bit. I agree: if a business analyst acts as an agent of the customer, helping her refine vague business goals and identify smaller, more valuable subfeatures, then I find on oxymoron in &#8220;agile business analyst&#8221;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Tweets that mention The Agile Business Analyst is an Oxymoron &#124; Real Options blog -- Topsy.com</title>
		<link>http://decision-coach.com/the-agile-business-analyst-is-an-oxymoron/comment-page-1/#comment-1120</link>
		<dc:creator>Tweets that mention The Agile Business Analyst is an Oxymoron &#124; Real Options blog -- Topsy.com</dc:creator>
		<pubDate>Fri, 25 Jun 2010 18:34:57 +0000</pubDate>
		<guid isPermaLink="false">http://decision-coach.com/?p=215#comment-1120</guid>
		<description>[...] This post was mentioned on Twitter by ellen gottesdiener, Dan Rough. Dan Rough said: Really enjoyed @PapaChrisMatts post http://bit.ly/c9lqFh particularly his point about &quot;Delivering business value OVER Working Software&quot; [...]</description>
		<content:encoded><![CDATA[<p>[...] This post was mentioned on Twitter by ellen gottesdiener, Dan Rough. Dan Rough said: Really enjoyed @PapaChrisMatts post <a href="http://bit.ly/c9lqFh" rel="nofollow">http://bit.ly/c9lqFh</a> particularly his point about &quot;Delivering business value OVER Working Software&quot; [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ellen Gottesdiener</title>
		<link>http://decision-coach.com/the-agile-business-analyst-is-an-oxymoron/comment-page-1/#comment-1119</link>
		<dc:creator>Ellen Gottesdiener</dc:creator>
		<pubDate>Fri, 25 Jun 2010 16:12:08 +0000</pubDate>
		<guid isPermaLink="false">http://decision-coach.com/?p=215#comment-1119</guid>
		<description>Good post Chris!

[ And thanks for noting my blog post &quot;Agile Requirements: Not an Oxymoron&quot; at http://ebgconsulting.com/blog/agile-requirements-not-an-oxymoron/ and also referencing my first book, Requirements by Collaboration (http://ebgconsulting.com/Pubs/reqtcoll.php ;-) ]

Chris: i appreciate you pointing out the agile business analysis, while an evolving practice, rests on good analysis and blends a)domain knowledge b) technology knowledge and c) business analysis skills.

i really like the term &quot;Business Coach&quot; (and that alternative role name has been picked up in the draft Intro section to the IIBA BABOK agile extension) -- so thanks! ;-)

For your readers interested in more: going to http://agileba.pbworks.com/ and joining in on conversations on the yahoo group you moderate could be of interest. 

Also, agile analysts interested in helping with our efforts to build agile extension to the IIBA BABOK: please consider contacting Dave Morris (our &quot;scrum master&quot; for the effort) via &quot;david.morris AT theiiba DOT org -- we can use more volunteers!

with warm regards,
~ ellen 


P.S. oh, it&#039;s spelled Gottesdiener (a mouthful, to be sure!)</description>
		<content:encoded><![CDATA[<p>Good post Chris!</p>
<p>[ And thanks for noting my blog post "Agile Requirements: Not an Oxymoron" at <a href="http://ebgconsulting.com/blog/agile-requirements-not-an-oxymoron/" rel="nofollow">http://ebgconsulting.com/blog/agile-requirements-not-an-oxymoron/</a> and also referencing my first book, Requirements by Collaboration (<a href="http://ebgconsulting.com/Pubs/reqtcoll.php" rel="nofollow">http://ebgconsulting.com/Pubs/reqtcoll.php</a> <img src='http://decision-coach.com/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' />  ]</p>
<p>Chris: i appreciate you pointing out the agile business analysis, while an evolving practice, rests on good analysis and blends a)domain knowledge b) technology knowledge and c) business analysis skills.</p>
<p>i really like the term &#8220;Business Coach&#8221; (and that alternative role name has been picked up in the draft Intro section to the IIBA BABOK agile extension) &#8212; so thanks! <img src='http://decision-coach.com/wp-includes/images/smilies/icon_wink.gif' alt=';-)' class='wp-smiley' /> </p>
<p>For your readers interested in more: going to <a href="http://agileba.pbworks.com/" rel="nofollow">http://agileba.pbworks.com/</a> and joining in on conversations on the yahoo group you moderate could be of interest. </p>
<p>Also, agile analysts interested in helping with our efforts to build agile extension to the IIBA BABOK: please consider contacting Dave Morris (our &#8220;scrum master&#8221; for the effort) via &#8220;david.morris AT theiiba DOT org &#8212; we can use more volunteers!</p>
<p>with warm regards,<br />
~ ellen </p>
<p>P.S. oh, it&#8217;s spelled Gottesdiener (a mouthful, to be sure!)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: David W. Wright</title>
		<link>http://decision-coach.com/the-agile-business-analyst-is-an-oxymoron/comment-page-1/#comment-1117</link>
		<dc:creator>David W. Wright</dc:creator>
		<pubDate>Fri, 25 Jun 2010 01:39:33 +0000</pubDate>
		<guid isPermaLink="false">http://decision-coach.com/?p=215#comment-1117</guid>
		<description>Business Analysis as most commonly understood today is about defining Business Requirements so that solutions can be identified, built/bought/borrowed, and delivered. 

I am of the thought that Agile is about building software that comprises or is part of a solution. It is very possible, doubters aside, to define clear, correct and complete requirements in a short time frame, before even deciding if you are building a solution, and that Agile is the approach you might use to do that.

So,we don&#039;t need to worry about this issue...sorry.</description>
		<content:encoded><![CDATA[<p>Business Analysis as most commonly understood today is about defining Business Requirements so that solutions can be identified, built/bought/borrowed, and delivered. </p>
<p>I am of the thought that Agile is about building software that comprises or is part of a solution. It is very possible, doubters aside, to define clear, correct and complete requirements in a short time frame, before even deciding if you are building a solution, and that Agile is the approach you might use to do that.</p>
<p>So,we don&#8217;t need to worry about this issue&#8230;sorry.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

