<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Thinking and Making: Comments by Anders Ramsay</title>
    <link>http://www.thinkingandmaking.com/person/23461</link>
    <pubDate>Tue, 14 Apr 2009 21:05:41 GMT</pubDate>
    <description>Comments by Anders Ramsay</description>
    <item>
      <description>&lt;p&gt;As usual, Austin, you are correct &amp;#8211; I do disagree with you : -)&lt;/p&gt;

	&lt;p&gt;Thanks to Cennydd&amp;#8217;s comments above, I do however not need to elaborate much on why, except to say that I largely agree with him, with a couple additional notes&amp;#8230;&lt;/p&gt;

	&lt;p&gt;Lest we forget, Agile was originated back in 2001 by a group of enterprise software developers for the purpose of finding common ground across several light-weight development methodologies.  In other words, they had their hands full trying to agree on the software side of things, not to speak of the UX/design side (and at least a few of those who were there lamented that other disciplines could not have been represented).&lt;/p&gt;

	&lt;p&gt;That said, while I absolutely agree with Cennydd that Agile is more than about management&amp;#8212;way more in fact&amp;#8212;and that it really is more of a philosophy, what is perhaps even more important is that it is a &lt;i&gt;work in progress&lt;/i&gt;, which is why I prefer the term used by several of the original signatories, referring to Agile as a movement. (I find Jeff Patton&amp;#8217;s definition of it as a &amp;#8216;quality&amp;#8217; to be bit mushy.)&lt;/p&gt;

	&lt;p&gt;The point here is that the ideas underlying Agile can and should be applied to Agile itself &amp;#8211; Agile ideas themselves are in a state of continual refinement and evolution, particularly as we now are exploring ways to unify Agile and UX practices.&lt;/p&gt;

	&lt;p&gt;So when we talk about that Agile means this or that, I think we are confining ourselves to some unhealthy orthodoxy.  So, should design and development happen in the same iteration or should they be uncoupled?  There really is no correct answer to this question because it will always depend on the particular situation.&lt;/p&gt;

	&lt;p&gt;That said, in my experience, trying to confine the UX work to the same iteration simply has not worked or made sense.  I&amp;#8217;ve talked to several other Agile/UX folks who have had the same experience, and would say that UX needs to be uncoupled from Agile, with parallel iterations, in which UX is one or two iterations ahead (though getting too far ahead can lead to a different set of problems.)&lt;/p&gt;

	&lt;p&gt;In other words, while I disagree re. the mgt thing, I actually think we agree on most other fronts.&lt;/p&gt;</description>
      <link>http://www.thinkingandmaking.com/view/agile-ux-un#content_35632</link>
      <guid>http://www.thinkingandmaking.com/view/agile-ux-un#content_35632</guid>
      <pubDate>Tue, 14 Apr 2009 21:05:41 GMT</pubDate>
      <author>Anders Ramsay</author>
    </item>
    <item>
      <description>&lt;p&gt;Wow, Austin, you need to do more ranting!  Yes, I had similar sentiments when I saw that email but you really hit the hammer on the head by calling the other team members out on not being good team players.  I really hope they read this post.&lt;/p&gt;</description>
      <link>http://www.thinkingandmaking.com/view/agile-ux-remembering#content_53785</link>
      <guid>http://www.thinkingandmaking.com/view/agile-ux-remembering#content_53785</guid>
      <pubDate>Wed, 19 May 2010 02:02:25 GMT</pubDate>
      <author>Anders Ramsay</author>
    </item>
  </channel>
</rss>

