I found the section of the paper where he talks about skills and competencies quite interesting - the suggestion seems to be that for any given task the least skilled person for that task should be the one to do it but that the person should still have the necessary competency to execute it. I’m not entirely sure of the distinction between skills and competencies - Belshee suggests:

There is a nice quote from the paper when discussing the idea of giving tasks to the least qualified person, that 'the least qualified teams produced the code that had the fewest surprises' - I imagine this is probably down to the fact that the least qualified person probably doesn’t yet know how to do clever things with a language so they just do the most obvious implementation. I think this is certainly what we want to happen when a team is working on code together.

I liked the discussion of beginner’s mind where he talks about it being a transitionary state that we move into when are in a situation that is unfamiliar but near the limits of our comfort zone and that we will move out of once we are comfortable with the current situation. It seems like this state of mind links quite closely with the idea of deliberate practice that Geoff Colvin talks about in 'Talent is Overrated' - the idea being that in order to improve most effectively we need to be doing activities which are just beyond our current competence.

I’ve frequently noticed that people are reluctant to swap pairs until they have finished the story that they’re working on - Matt Dunn pointed out that this is probably linked to human’s natural desire to finish what they’ve started! Belshee seems to get around this problem by ensuring that the tasks being worked on are sufficiently small in size that they can be completed within one or two pairing sessions. A lot of the work that we do is integrating different systems where there is quite a bit of exploratory work to find out what we actually need to do first - it would be interesting to see if quicker rotations would be appropriate for this type of work or whether a lot of time would be spent bringing the new person on the pair up to speed with what’s going on.

We had some discussion on pair programming in general - Raphael Speyer described the idea of 'promiscuous keyboarding' as an approach to try within a single pair. The idea is that the keyboard switches between each person every minute which hopefully leads to both people being more engaged. I find that quite often on teams people will roll in and out of pairs when there help is needed on something - Nic Snoek described this as being 'guerilla pairing' and I think it is something that a technical lead of a team is most likely to engage in as they move around the room helping people out.