<?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 Cennydd Bowles</title>
    <link>http://www.thinkingandmaking.com/person/28284</link>
    <pubDate>Tue, 07 Apr 2009 11:51:48 GMT</pubDate>
    <description>Comments by Cennydd Bowles</description>
    <item>
      <description>&lt;p&gt;I disagree slightly, in that I don&amp;#8217;t see Agile as a way to &amp;#8216;manage stuff&amp;#8217; or a &amp;#8216;development method&amp;#8217;, To me, it&amp;#8217;s a philosophy of focusing on the bits that matter and getting things out there quickly. I think that&amp;#8217;s very much compatible with UX; sure, we need to adapt our toolset, but it&amp;#8217;s doable in many circumstances (not all). Not sure if you read my &lt;span class="caps"&gt;ALA&lt;/span&gt; article, but it gives a stab at some techniques I&amp;#8217;ve found useful: &lt;a href="http://www.alistapart.com/articles/gettingrealaboutagiledesign" rel="nofollow"&gt;http://www.alistapart.com/articles/gettingrealaboutagiled&amp;hellip;&lt;/a&gt;&lt;/p&gt;

	&lt;p&gt;Anyway, what really interests me is your last question: &amp;#8220;How do agile development methods measure user experience?&amp;#8221;&lt;/p&gt;

	&lt;p&gt;Good question. I&amp;#8217;ve actually got a proposal in for the Agile2009 conference about this. My experience of the status quo is that, basically, UX doesn&amp;#8217;t get managed. In a lot of so-called Agile projects, UX seems to live &amp;#8216;off the grid&amp;#8217;, with design activities largely separate from development.&lt;/p&gt;

	&lt;p&gt;I don&amp;#8217;t like this approach, since it limits collaboration and misses the opportunity to demonstrate why UX design is as important to the project as development. After all, much of our work is intangible and I think we need all the help we can get when justifying our activities and RoI.&lt;/p&gt;

	&lt;p&gt;So I&amp;#8217;ve been thinking about and experimenting where possible with things like exposing UX estimates at iteration planning sessions, including design progress on burndown charts (although is design really reducible in this way?), and even setting up semi-formal acceptance criteria via quantitative testing per iteration.&lt;/p&gt;

	&lt;p&gt;But I think it&amp;#8217;s easy to go too far, however. I&amp;#8217;ve worked in environments similar to Doug Bowman&amp;#8217;s recent Google experience [&lt;a href="http://stopdesign.com/archive/2009/03/20/goodbye-google.html" rel="nofollow"&gt;http://stopdesign.com/archive/2009/03/20/goodbye-google.h&amp;hellip;&lt;/a&gt;] where A/B tests and multivariate testing have a stranglehold over the site&amp;#8217;s evolution. For obvious reasons this is antithetical to good user experience. So I think, if we are to measure this stuff, we need to do it in as lightweight a way as possible. I also worry whether over-zealous management can hamper the formation of a coherent design vision, and whether measurement affects velocity itself (an Agile version of Heisenberg&#8217;s Uncertainty Principle, if you like).&lt;/p&gt;

	&lt;p&gt;Be interested to hear your thoughts (and others&amp;#8217;) &#8211; as you say Austin, this is an important question and the sooner we can find some answers, the better.&lt;/p&gt;</description>
      <link>http://www.thinkingandmaking.com/view/agile-ux-un#content_35462</link>
      <guid>http://www.thinkingandmaking.com/view/agile-ux-un#content_35462</guid>
      <pubDate>Tue, 07 Apr 2009 11:51:48 GMT</pubDate>
      <author>Cennydd Bowles</author>
    </item>
    <item>
      <description>&lt;p&gt;Austin &#8211; better late than never, but thank you for this post. I refer to it all the damn time.&lt;/p&gt;</description>
      <link>http://www.thinkingandmaking.com/view/more-tips-for#content_54388</link>
      <guid>http://www.thinkingandmaking.com/view/more-tips-for#content_54388</guid>
      <pubDate>Fri, 04 Jun 2010 12:14:32 GMT</pubDate>
      <author>Cennydd Bowles</author>
    </item>
  </channel>
</rss>

