<?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: Agile is the only way to build SharePoint applications.</title>
	<atom:link href="http://blog.glenc.net/2007/06/15/agile-is-the-only-way-to-build-sharepoint-applications/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.glenc.net/2007/06/15/agile-is-the-only-way-to-build-sharepoint-applications/</link>
	<description>Treading water in a sea of man-made confusion.</description>
	<lastBuildDate>Fri, 10 Jun 2011 04:47:02 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.3</generator>
	<item>
		<title>By: Tim</title>
		<link>http://blog.glenc.net/2007/06/15/agile-is-the-only-way-to-build-sharepoint-applications/comment-page-1/#comment-5688</link>
		<dc:creator>Tim</dc:creator>
		<pubDate>Mon, 02 Jun 2008 14:35:07 +0000</pubDate>
		<guid isPermaLink="false">http://blogtmp.glenc.net/2007/06/15/agile-is-the-only-way-to-build-sharepoint-applications/#comment-5688</guid>
		<description>Glen I take just about everything you said verbatim. The only point I have trouble with is point 2. in your benefits list &quot;Wireframes and UI designs are less critical because you can “design” on the fly using the out of the box UI - then identify the gaps where additional design elements or controls are needed.&quot;

Taking an Agile approach gives a designer more data to use in the design process but SP OOTB UI is not an Agile shortcut to UI design. Design is still required as UI design should not be driven by one UI view of the world. UI design criticality remains unchanged.</description>
		<content:encoded><![CDATA[<p>Glen I take just about everything you said verbatim. The only point I have trouble with is point 2. in your benefits list &#8220;Wireframes and UI designs are less critical because you can “design” on the fly using the out of the box UI &#8211; then identify the gaps where additional design elements or controls are needed.&#8221;</p>
<p>Taking an Agile approach gives a designer more data to use in the design process but SP OOTB UI is not an Agile shortcut to UI design. Design is still required as UI design should not be driven by one UI view of the world. UI design criticality remains unchanged.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ricky</title>
		<link>http://blog.glenc.net/2007/06/15/agile-is-the-only-way-to-build-sharepoint-applications/comment-page-1/#comment-1407</link>
		<dc:creator>Ricky</dc:creator>
		<pubDate>Sat, 09 Feb 2008 21:47:26 +0000</pubDate>
		<guid isPermaLink="false">http://blogtmp.glenc.net/2007/06/15/agile-is-the-only-way-to-build-sharepoint-applications/#comment-1407</guid>
		<description>Wow. I think this single post might just break us out of the analysis paralysis hole that we&#039;re just starting to realize we&#039;ve been digging. We have been waterfalling hard. We&#039;ve started with trying to come up with every user/scenario/need permutation that &quot;might&quot;  one day be requested, then trying to go through each part of the product to see what we would have to do to prepare for it, then figure out how to actually change it. And our case is even worse - we essentially can start with a blank slate; there&#039;s really no solution or user requirements other then our (I.S.) best (non-user) guesses!

What we really should be doing is going with the defaults that have been defined for a good reason. If some thing&#039;s not working, you then have to make the argument as to why the default won&#039;t work for you and then implement the customization in the least invasive way to make them happy.

We&#039;re spending a majority of our time in over-designing something that will handle all potential things for all potential people. In reality it&#039;s pretty much there now, and for the things that do pop up there&#039;s usually a solution with negligent impact. 

Thank you!</description>
		<content:encoded><![CDATA[<p>Wow. I think this single post might just break us out of the analysis paralysis hole that we&#8217;re just starting to realize we&#8217;ve been digging. We have been waterfalling hard. We&#8217;ve started with trying to come up with every user/scenario/need permutation that &#8220;might&#8221;  one day be requested, then trying to go through each part of the product to see what we would have to do to prepare for it, then figure out how to actually change it. And our case is even worse &#8211; we essentially can start with a blank slate; there&#8217;s really no solution or user requirements other then our (I.S.) best (non-user) guesses!</p>
<p>What we really should be doing is going with the defaults that have been defined for a good reason. If some thing&#8217;s not working, you then have to make the argument as to why the default won&#8217;t work for you and then implement the customization in the least invasive way to make them happy.</p>
<p>We&#8217;re spending a majority of our time in over-designing something that will handle all potential things for all potential people. In reality it&#8217;s pretty much there now, and for the things that do pop up there&#8217;s usually a solution with negligent impact. </p>
<p>Thank you!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Henry</title>
		<link>http://blog.glenc.net/2007/06/15/agile-is-the-only-way-to-build-sharepoint-applications/comment-page-1/#comment-267</link>
		<dc:creator>Henry</dc:creator>
		<pubDate>Thu, 21 Jun 2007 00:05:19 +0000</pubDate>
		<guid isPermaLink="false">http://blogtmp.glenc.net/2007/06/15/agile-is-the-only-way-to-build-sharepoint-applications/#comment-267</guid>
		<description>Kudos Glen! Thanks for the insight.</description>
		<content:encoded><![CDATA[<p>Kudos Glen! Thanks for the insight.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

