<?xml version="1.0" encoding="UTF-8"?>
<feed xml:lang="en-US" xmlns="http://www.w3.org/2005/Atom">
  <title>andthennothing.net: Tag agile</title>
  <subtitle type="html">&amp;ldquo;first there was a three-legged monkey...&amp;rdquo;</subtitle>
  <id>tag:andthennothing.net,2005:Typo</id>
  <generator uri="http://typo.leetsoft.com" version="4.0">Typo</generator>
  <link href="http://andthennothing.net/xml/atom10/tag/agile/feed.xml" rel="self" type="application/xml+atom"/>
  <link href="http://andthennothing.net/tags/agile?tag=agile" rel="alternate" type="text/html"/>
  <updated>2005-12-18T03:19:08+00:00</updated>
  <entry>
    <author>
      <name>Jonas Bengtsson</name>
      <email>jonas.b@home.se</email>
    </author>
    <id>urn:uuid:b7e166f1-240b-4c44-b10c-245a5e2a9fa5</id>
    <published>2005-10-05T21:39:00+00:00</published>
    <updated>2005-12-18T03:19:08+00:00</updated>
    <title>Promiscuous pairing</title>
    <link href="http://andthennothing.net/archives/2005/10/05/promiscuous-pairing" rel="alternate" type="text/html"/>
    <category term="pairprogramming" scheme="http://andthennothing.net/tags/agile"/>
    <category term="xp" scheme="http://andthennothing.net/tags/agile"/>
    <category term="agile" scheme="http://andthennothing.net/tags/agile"/>
    <category term="productivity" scheme="http://andthennothing.net/tags/agile"/>
    <category term="knowledge" scheme="http://andthennothing.net/tags/agile"/>
    <content type="html">&lt;p&gt;Via the &lt;a href="http://agiletoolkit.libsyn.com/index.php?post_id=15636"&gt;Agile Toolkit Podcast&lt;/a&gt; I discovered the article &lt;a href="http://www.agile2005.org/XR4.pdf"&gt;Promiscuous Pairing and Beginner’s Mind: Embrace Inexperience&lt;/a&gt; by Arlo Belshee. It&amp;#8217;s been a while since I&amp;#8217;ve read such an interesting article!&lt;/p&gt;


Arlo describes how Silver Platter have experimented with different approaches to pair programming and task ownership/distribution. And most of their findings are not what you expect, and often they contradict commonly held truths. Some of them are:
	&lt;ul&gt;
	&lt;li&gt;assigning tasks to the least qualified worked better long term than assigning to the most qualified or randomly&lt;/li&gt;
		&lt;li&gt;team ownership of the tasks (team accountability) worked better than individual ownership (individual accountability)&lt;/li&gt;
		&lt;li&gt;task grabbing (pull) worked better than assignment (push)&lt;/li&gt;
		&lt;li&gt;swapping pairs each 90 minutes was most productive&lt;/li&gt;
		&lt;li&gt;for time between swaps of one hour to a day it was more productive if the one who had been with the task the longest switches task than if one stayed with a task until its completion&lt;/li&gt;
	&lt;/ul&gt;


	&lt;p&gt;&lt;a href="http://www.agile2005.org/XR4.pdf"&gt;Go read the whole article now!&lt;/a&gt;&lt;/p&gt;


	&lt;p&gt;Oh, and that they use C++ makes it even more interesting!&lt;/p&gt;</content>
  </entry>
  <entry>
    <author>
      <name>Jonas Bengtsson</name>
      <email>jonas.b@home.se</email>
    </author>
    <id>urn:uuid:3ab3dab5-effb-4e0e-8ed6-8a485f7ee4e8</id>
    <published>2005-07-16T21:45:00+00:00</published>
    <updated>2005-12-18T03:19:03+00:00</updated>
    <title>Jason Fried on work process</title>
    <link href="http://andthennothing.net/archives/2005/07/16/jason-fried-on-work-process" rel="alternate" type="text/html"/>
    <category term="documentation" scheme="http://andthennothing.net/tags/agile"/>
    <category term="planning" scheme="http://andthennothing.net/tags/agile"/>
    <category term="agile" scheme="http://andthennothing.net/tags/agile"/>
    <content type="html">&lt;a href="http://www.37signals.com/svn/"&gt;Jason Fried&lt;/a&gt; in an &lt;a href="http://www.tompeters.com/cool_friends/content.php?note=007936.php"&gt;interview&lt;/a&gt; with &lt;a href="http://www.tompeters.com"&gt;Tom Peters&lt;/a&gt;:
	&lt;blockquote&gt;
		&lt;p&gt;We&amp;#8217;re not much into planning or writing a lot of things down that are concrete. My personal opinion is that every decision you make should be temporary. So when you start writing things down, you start putting signatures to things, and you start being locked into your past actions. You&amp;#8217;re letting your past determine the future. So I prefer to just start designing and see where things go. Then you can make adjustments and tweaks, realizing that every decision you make and everything you do can be changed if you come up with something better. I think that&amp;#8217;s the best way to design things. &lt;br /&gt;&lt;br/&gt;It also lets you make decisions when you have the right information to make them. The traditional design process might include a lot of documentation of functional specifications, or lots of charts and diagrams, and a bunch of stuff that you compile before you begin designing. In reality, you can plan all you want, but by the time you start actually designing something, and using it in the real world, you start seeing patterns and things you never could&amp;#8217;ve guessed before. If you&amp;#8217;re locked into a plan, then you can&amp;#8217;t change those things.&lt;/p&gt;
	&lt;/blockquote&gt;</content>
  </entry>
</feed>
