<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Boxes and Arrows: Comments by Lexi Thorn</title>
    <link>http://www.boxesandarrows.com/person/132439</link>
    <pubDate>Tue, 09 Feb 2010 02:46:59 GMT</pubDate>
    <description>Comments by Lexi Thorn</description>
    <item>
      <description>&lt;p&gt;Great article Anthony.&lt;/p&gt;

	&lt;p&gt;One thing I&amp;#8217;ve noticed during the &amp;#8220;Agile &amp;#8216;v&amp;#8217; Waterfall&amp;#8221; debate is that there has been a strong focus on process and less of a focus on outcomes. Even though Agile is supposed to be a philosophy, it is commonly interpreted as a process (one of short development cycles and little or no upfront planning/strategy/research).  It shouldn&amp;#8217;t matter if a business calls how it works &amp;#8220;Waterfall&amp;#8221;, &amp;#8220;Agile&amp;#8221; or &amp;#8220;Watergile&amp;#8221; &amp;#8211; you need a way of working that produces the right outcomes for your team, client and the end user.&lt;/p&gt;

	&lt;p&gt;I think it&amp;#8217;s a great start for everyone in the team to sit together to find out how they&amp;#8217;d like to work through the project, instead of this being mandated by someone &amp;#8211; such as your Head of Product Development. Everyone in the team usually has some sort of idea of how they&amp;#8217;d like to work together and can assess what needs to be done, and this can be co-ordinated by the Project Manager.&lt;/p&gt;

	&lt;p&gt;You&amp;#8217;ll always need the pieces of the puzzle to put it together, but how you put it together should be decided by the team. The things that you know you need upfront, should be able to be done upfront. If you work for a company that has strong &lt;span class="caps"&gt;UCD&lt;/span&gt; focus, this would usually mean some form of user research would be conducted to help define the goals and vision of the product. This doesn&amp;#8217;t mean that stacks of documentation is going to be created then handed to developers. Personally as a UX designer, I like working with developers in a low documentation, modular, highly iterative environment, but only when the core principles and interaction framework is defined up front &amp;#8211; like in your &amp;#8220;Best of Both Worlds&amp;#8221; diagram.&lt;/p&gt;

	&lt;p&gt;Most people enjoy working in the buzz of a collaborative team environment, where what you produce as a team is better than what you could&amp;#8217;ve created as an individual (the whole is greater than the sum of its parts). However, it&amp;#8217;s important to think through how you&amp;#8217;re your going to get there, so the right inputs and steps are taken to achieve the right outcomes.&lt;/p&gt;</description>
      <link>http://www.boxesandarrows.com/view/bringing-user#content_51334</link>
      <guid>http://www.boxesandarrows.com/view/bringing-user#content_51334</guid>
      <pubDate>Tue, 09 Feb 2010 02:46:59 GMT</pubDate>
      <author>Lexi Thorn</author>
    </item>
  </channel>
</rss>

