<?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 Wrap-Up</title>
	<atom:link href="http://www.agilekiwi.com/other/agile/pair-programming-wrap-up/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.agilekiwi.com/other/agile/pair-programming-wrap-up/</link>
	<description>The neglected essentials of software development</description>
	<lastBuildDate>Mon, 20 May 2013 23:01:11 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
	<item>
		<title>By: John Rusk</title>
		<link>http://www.agilekiwi.com/other/agile/pair-programming-wrap-up/comment-page-1/#comment-639</link>
		<dc:creator>John Rusk</dc:creator>
		<pubDate>Sun, 15 Jul 2012 01:22:15 +0000</pubDate>
		<guid isPermaLink="false">http://www.agilekiwi.com/?p=728#comment-639</guid>
		<description><![CDATA[Interesting.  If I understand correctly, the reason why cycle time is not harmed by pairing is as per your comment here http://www.agilekiwi.com/other/agile/expertise-meets-pair-programming/

By the way, if a (non-blocked) pair cycles at the same rate as a (non-blocked) solo, then superficially that would suggest that pairing takes twice as many person-hours to accomplish the same work. Of course, as you say, pairs remain non-blocked for a greater percentage of time than solos. From your measurements, are you able to guestimate the overall cost-effectiveness of pairing versus soloing?.  (Bearing in mind not just cycle times, but also different defect rates and therefore different costs of defect resolution.  And also faster learning, as per your recent comment on your own blog - http://arlobelshee.com/post/is-pair-programming-for-me).]]></description>
		<content:encoded><![CDATA[<p>Interesting.  If I understand correctly, the reason why cycle time is not harmed by pairing is as per your comment here <a href="http://www.agilekiwi.com/other/agile/expertise-meets-pair-programming/" rel="nofollow">http://www.agilekiwi.com/other/agile/expertise-meets-pair-programming/</a></p>
<p>By the way, if a (non-blocked) pair cycles at the same rate as a (non-blocked) solo, then superficially that would suggest that pairing takes twice as many person-hours to accomplish the same work. Of course, as you say, pairs remain non-blocked for a greater percentage of time than solos. From your measurements, are you able to guestimate the overall cost-effectiveness of pairing versus soloing?.  (Bearing in mind not just cycle times, but also different defect rates and therefore different costs of defect resolution.  And also faster learning, as per your recent comment on your own blog &#8211; <a href="http://arlobelshee.com/post/is-pair-programming-for-me" rel="nofollow">http://arlobelshee.com/post/is-pair-programming-for-me</a>).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Arlo Belshee</title>
		<link>http://www.agilekiwi.com/other/agile/pair-programming-wrap-up/comment-page-1/#comment-637</link>
		<dc:creator>Arlo Belshee</dc:creator>
		<pubDate>Sat, 14 Jul 2012 17:48:13 +0000</pubDate>
		<guid isPermaLink="false">http://www.agilekiwi.com/?p=728#comment-637</guid>
		<description><![CDATA[Experts need not take longer cycles in pairs than they do solo. In fact, if you stand back and watch with a stopwatch, you might find a surprising result.

When I&#039;ve done this, I found that pairs cycled more quickly. They actually tried more ideas per unit time. My observation was that pairs went the same speed when they weren&#039;t blocked and they were blocked less frequently and for shorter periods.

And when questioned, the pairs nearly always reported that they were cycling more slowly. People didn&#039;t feel the blocks when they were solo (because they were thinking?). They did feel the drag of conversation.

My teammates were really surprised by the results. So we re-ran with each of them being observer for a half-day. We still had trouble believing the stopwatch, but the evidence was clear.]]></description>
		<content:encoded><![CDATA[<p>Experts need not take longer cycles in pairs than they do solo. In fact, if you stand back and watch with a stopwatch, you might find a surprising result.</p>
<p>When I&#8217;ve done this, I found that pairs cycled more quickly. They actually tried more ideas per unit time. My observation was that pairs went the same speed when they weren&#8217;t blocked and they were blocked less frequently and for shorter periods.</p>
<p>And when questioned, the pairs nearly always reported that they were cycling more slowly. People didn&#8217;t feel the blocks when they were solo (because they were thinking?). They did feel the drag of conversation.</p>
<p>My teammates were really surprised by the results. So we re-ran with each of them being observer for a half-day. We still had trouble believing the stopwatch, but the evidence was clear.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John Rusk</title>
		<link>http://www.agilekiwi.com/other/agile/pair-programming-wrap-up/comment-page-1/#comment-585</link>
		<dc:creator>John Rusk</dc:creator>
		<pubDate>Sat, 10 Mar 2012 20:15:59 +0000</pubDate>
		<guid isPermaLink="false">http://www.agilekiwi.com/?p=728#comment-585</guid>
		<description><![CDATA[BTW there is an interesting counter-argument here http://www.higherorderlogic.com/2008/06/test-driven-development-a-cognitive-justification/ , in which it is suggested that we _should_ aim to slow experts down.  I&#039;m not sure I buy it, but I do find it interesting]]></description>
		<content:encoded><![CDATA[<p>BTW there is an interesting counter-argument here <a href="http://www.higherorderlogic.com/2008/06/test-driven-development-a-cognitive-justification/" rel="nofollow">http://www.higherorderlogic.com/2008/06/test-driven-development-a-cognitive-justification/</a> , in which it is suggested that we _should_ aim to slow experts down.  I&#8217;m not sure I buy it, but I do find it interesting</p>
]]></content:encoded>
	</item>
</channel>
</rss>
