<?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/"
		>
<channel>
	<title>Comments on: Pair Programming &#8211; My perspective.</title>
	<atom:link href="http://martinaharris.com/2009/11/pair-programming-perspective/feed/" rel="self" type="application/rss+xml" />
	<link>http://martinaharris.com/2009/11/pair-programming-perspective/</link>
	<description>Next time you look it might be gone</description>
	<lastBuildDate>Tue, 13 Jul 2010 22:32:05 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
	<item>
		<title>By: Dave Rooney</title>
		<link>http://martinaharris.com/2009/11/pair-programming-perspective/#comment-11</link>
		<dc:creator>Dave Rooney</dc:creator>
		<pubDate>Wed, 02 Dec 2009 01:01:17 +0000</pubDate>
		<guid isPermaLink="false">http://martinaharris.com/?p=401#comment-11</guid>
		<description>Nice post!  The point about the overall throughput increase is also one that I have experienced.

&quot;Its very hard work.  In fact its exhausting.&quot;

Absolutely, and I found this from the first time I tried pairing in 2000.  When I coach teams, though, I use a concept called &quot;Core Hours&quot;.  That&#039;s usually something like 9:00 AM to 3:00 PM or 9:30 to 3:30 with 30 mins to 1 hour for lunch.  During that time, the team is doing nothing but work on the project.  Outside of Code Hours, though, the team members can do any of the administrivia, phone calls, e-mails, general surfing, etc. that would distract them otherwise.

The reaction of management is usually that they would like longer Core Hours, but that goes away after an iteration or two where they see the productivity actually go up when the team members are working 5 dedicated hours rather than 8 distracted ones.

The Core Hours concept also helps with fatigue.  If you&#039;re only pairing for 5 hours of the day, you&#039;re better able to rest and be fresh the next day.  Of course, there&#039;s flexibility around all of this - I wouldn&#039;t tell a team that&#039;s in the middle of something that Core Hours are over and they should stop!

Dave Rooney
The Agile Consortium</description>
		<content:encoded><![CDATA[<p>Nice post!  The point about the overall throughput increase is also one that I have experienced.</p>
<p>&#8220;Its very hard work.  In fact its exhausting.&#8221;</p>
<p>Absolutely, and I found this from the first time I tried pairing in 2000.  When I coach teams, though, I use a concept called &#8220;Core Hours&#8221;.  That&#8217;s usually something like 9:00 AM to 3:00 PM or 9:30 to 3:30 with 30 mins to 1 hour for lunch.  During that time, the team is doing nothing but work on the project.  Outside of Code Hours, though, the team members can do any of the administrivia, phone calls, e-mails, general surfing, etc. that would distract them otherwise.</p>
<p>The reaction of management is usually that they would like longer Core Hours, but that goes away after an iteration or two where they see the productivity actually go up when the team members are working 5 dedicated hours rather than 8 distracted ones.</p>
<p>The Core Hours concept also helps with fatigue.  If you&#8217;re only pairing for 5 hours of the day, you&#8217;re better able to rest and be fresh the next day.  Of course, there&#8217;s flexibility around all of this &#8211; I wouldn&#8217;t tell a team that&#8217;s in the middle of something that Core Hours are over and they should stop!</p>
<p>Dave Rooney<br />
The Agile Consortium</p>
]]></content:encoded>
	</item>
</channel>
</rss>

