<?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/"
	xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
xmlns:rawvoice="http://www.rawvoice.com/rawvoiceRssModule/"
	>
<channel>
	<title>Comments on: Hugh Beyer &#8211; Getting Started with UX Inside Agile Development</title>
	<atom:link href="http://www.uie.com/brainsparks/2012/03/16/hugh-beyer-ux-inside-agile/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.uie.com/brainsparks/2012/03/16/hugh-beyer-ux-inside-agile/</link>
	<description>UIE\'s latest insights on the world of design</description>
	<lastBuildDate>Wed, 22 May 2013 18:03:42 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.4.1</generator>
	<item>
		<title>By: Craig Sullivan</title>
		<link>http://www.uie.com/brainsparks/2012/03/16/hugh-beyer-ux-inside-agile/comment-page-1/#comment-210428</link>
		<dc:creator>Craig Sullivan</dc:creator>
		<pubDate>Tue, 20 Mar 2012 17:48:56 +0000</pubDate>
		<guid isPermaLink="false">http://www.uie.com/brainsparks/?p=6602#comment-210428</guid>
		<description>Excellent interview and thanks both of you for the thinking.

We&#039;ve been experimenting a lot over the last 18 months and use a variety of techniques now - we&#039;re not dogmatic about Agile, which some people get caught up in.

The one thing I&#039;ve learned is complete integration of the research, prototyping, user testing, development iterations, feedback (analytics, session recording, VOC) and measurement work into one team is what works best for us.

Our sprints shrink, grow, change, get optimistic, get pessimistic and change completely in character as the work moves forward.  We may have waypoints but they are not rigid like sprints are in some ways.  A good example is this one - let&#039;s say we have a prototype and have an insurance lookup system.  In the first usability test of the prototype, this might have been a freeform box.

We learned things and asked questions.  We then posted a response in the next iteration, which the developers helped us figure out - maybe not the completed article, but a dummy or fake system to test our hypothesis.  We then all watched the feedback and all worked on that field again, with a new UI pattern.  This means we&#039;re just improving stuff along a test cycle to begin with (to make test dates) but then during and post launch, we use a more optimisation and testing focused approach - to improve revenue too.

This is an example of where we might cut corners, finesse something, fake it, change it (to get insight from participants) or do a best effort to get a shippable prototype for the test.  The sprint is a flexible item, as are the contents.

I&#039;d love to do an interview sometime - I&#039;m not explaining this very well but it joins UX, Agile and then site optimisation techniques and works very well for us.  I think we&#039;re closest to Kanban but not big on naming things - just following the &#039;done&#039; manifesto .

C.</description>
		<content:encoded><![CDATA[<p>Excellent interview and thanks both of you for the thinking.</p>
<p>We&#8217;ve been experimenting a lot over the last 18 months and use a variety of techniques now &#8211; we&#8217;re not dogmatic about Agile, which some people get caught up in.</p>
<p>The one thing I&#8217;ve learned is complete integration of the research, prototyping, user testing, development iterations, feedback (analytics, session recording, VOC) and measurement work into one team is what works best for us.</p>
<p>Our sprints shrink, grow, change, get optimistic, get pessimistic and change completely in character as the work moves forward.  We may have waypoints but they are not rigid like sprints are in some ways.  A good example is this one &#8211; let&#8217;s say we have a prototype and have an insurance lookup system.  In the first usability test of the prototype, this might have been a freeform box.</p>
<p>We learned things and asked questions.  We then posted a response in the next iteration, which the developers helped us figure out &#8211; maybe not the completed article, but a dummy or fake system to test our hypothesis.  We then all watched the feedback and all worked on that field again, with a new UI pattern.  This means we&#8217;re just improving stuff along a test cycle to begin with (to make test dates) but then during and post launch, we use a more optimisation and testing focused approach &#8211; to improve revenue too.</p>
<p>This is an example of where we might cut corners, finesse something, fake it, change it (to get insight from participants) or do a best effort to get a shippable prototype for the test.  The sprint is a flexible item, as are the contents.</p>
<p>I&#8217;d love to do an interview sometime &#8211; I&#8217;m not explaining this very well but it joins UX, Agile and then site optimisation techniques and works very well for us.  I think we&#8217;re closest to Kanban but not big on naming things &#8211; just following the &#8216;done&#8217; manifesto .</p>
<p>C.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
