Pairing and productivity

Just been through a blog reading trail starting from Kathy Sierra’s “The Asymptiotic Twitter Curve” to Jason Fried’s “How to shut up and get to work” to Joel Sposky’s “The value of alone time” which all talks about individual productivity. The gist of those blogs is that we feel compelled to repetitively keep checking our email, IMing, answering phone calls, checking our blog stats etc without realising that it breaks our concentration and prevents us from going into a “zone”.

This led me to think about how Agile addresses the productivity issue. It was interesting to see that Agile considers colacated teams to contribute towards the overall productivty of the team. On the other hand, advocates of agile defend the loss of productivity when 2 people work on the same problem by offering reasons such as continuous code review, design brainstorming, risk mitigation against siloed knowledge etc. Based on the logic in those posts, productivity is actually helped through pairing and adversely affected by colocation.

One advantage of pair programming that my ex-colleague Ivan Moore mentioned to me was that out of politeness and respect for your pair,one would be less tempted to check for their emails or answer any phone calls or browse generally. The pairs keep each other honest and focussed on the task, and can crack on faster. Thus, what is lost in terms of having 2 people working on 1 problem is compensated by the increased and sustained focus on the task.

Agile advocates co-located team sitting in proximity for free flow of communication about project matters . Under such arrangement, a team member can potentially disturb another pair to ask about a problem that they might have tackled earlier. The benefit is that one does not have to solve the problem from scratch if other had done something similar earlier.

However, Joel observes that about 15 minutes of respondent’s time is wasted when they are interrupted in their work as they will now need to spend that time to get their concentration back. Joel’s observation is based on the fact that individual programmers have to juggle a lot of small details in a short memory and one loses that thread when they are interrupted. The process of re-organizing the data takes an investment of 15 minutes.

Now when I have been explaining a concept to someone and disturbed, I too have lost my thread and have had to repeat some of the things I may have already covered. However, if someone was listening keenly, they might be able to get me back on track again quicker without the need to repeat things.

Given this, my theory is that pairing would allow for all small details about the program to be jointly understood by each half of the pair and even if they get disturbed, they can make a faster recovery to get back on track and achieve their focus again. Thus, it might take only 7.5 minutes to get back to the problem for a pair who were interrupted as opposed to 15 minutes for an individual.

Has anyone got any empirical observations to back this up ?

Advertisements

3 Responses

  1. Hi mate! 🙂

    I don’t have empirical observations, but in my experience, pairs will often handle interruptions by letting only one of them be interrupted, while the other carries on working on the problem. This way they do not lose the line of thought, and need only a minute or so to get the interrupted person back up to speed.

  2. Hey Nils,

    Long time no hear. Its interesting what you mention – my 7.5 minutes was totally random of course. A minute lost is no minute at all and based on other conversations that I have been having, “Getting into the Zone” is actually overrated.

    Thanks for your comments. Do you blog as well ?

    regards,
    Prashant

  3. I noticed that James Shore describes the same observation in the pair programming chapter of his and chromatic’s forthcoming book The Art of Agile Development (being openly reviewed at http://www.jamesshore.com/Agile-Book/).

    I do a bit of writing, but I don’t have a public blog.

    Happy holidays!

    Cheers,
    Nils

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: