Promiscuous Pairing and Beginner’s Mind
Every Wednesday at Etermax, we gather with a group of colleagues to discuss a previously chosen book or article. A few weeks ago, we read “Promiscuous pairing and Beginner’s mind”, written by Arlo Belshee, and I found this paper deeply interesting.
Arlo Belshee is a Software Engineer and Consultor Agile Coach, with more than 20 years of experience. He has worked in well known companies such as Microsoft and Tableau. About 10 years ago, he and his team in Silver Platter Software conducted a series of experiments on the use of pair programming and pair swapping. The results of those studies were later presented in the mentioned paper.
Arlo Belshee’s paper
In his paper, Arlo talks about pair programming and how to achieve a ‘beginner’s mind’ (and what this means according to him). He says that they discovered that this state of mind is a very efficient way to solve programming problems. They carried out some experiments to try to reach this state, and to find the most effective way to apply pair programming.
What they found out:
What is to have a beginner’s mind?
It refers to having an attitude of openness, eagerness, and to lack preconceptions when studying a subject, even when at an advanced level, just as a beginner would do.
In a beginners mind there are many possibilities, but in the expert’s there are few.
Shunryu Suzuki
It must be remarked that this is a transitory state, and that you may rapidly exit the ‘beginner’s mind’. This is why Arlo and his team wanted to find out how to stay longer in this state.
What does Promiscuous Pairing mean?
Promiscuous means to change partners quickly. So what Arlo tries to convey with this concept is the idea of swapping peers more frequently than usual while pair programming, even before finishing the given task.
While you’re pair programming there is a transfer of knowledge between peers, so after switching pairs, knowledge is transferred around all participants. The author states that, generally, the most important information is transferred at the beginning. It could be anything: from using something from the IDE, or a TDD technique, or even about the language used.
By doing promiscuous pairing, there is a rapid transfer of knowledge between all the team.
Arlo Belshee
So… what does Arlo say about a ‘beginner’s mind’?
If we, programmers, could achieve this state of beginner’s mind, we should be able to code better. The problem is that, as I said before, this is a temporary state. As soon as you know what you are doing and you get involved for a time, you are no longer in that state.
Achieving a ‘beginner’s mind’
How can we achieve this state of ‘beginner’s mind’? By being promiscuous.
Arlo and his team experimented this by swapping partners every X amount of time (x-axis in hours) and logged the velocity that they had reached.
The dotted line shows a situation in which one developer works all the way through a certain task, and the one who changes is always the ‘guest’. In this example, there is always a task owner, that is, the person currently developing the feature. The solid line shows the alternating pair swap scenario (as the example given at the beginning of the article). In this case, there is no task owner, and probably more people will get involved in the task.
They concluded that swapping every 1.30 hs allowed them to reach their maximum performance .
Pros and cons
Applying promiscuous pairing effectively can result in these two major benefits:
* Training task owners, not domain experts. This means that everyone in the team will be able to carry out virtually any task, regardless of any casualties that might occur (e.g. somebody is on vacation or has called in sick)
* Rapid spreading of knowledge between all the members of the team.
On the negative side, an issue that I identified after talking with people and teams that have tried this technique, is the mental fatigue from pair programming all day and ‘starting’ a new feature several times.
Final thoughts
It may seem that I have already experimented what I have just described, but I still haven’t. I encourage you to try it out, and tell us about the outcome.
I contacted Arlo over LinkedIn to tell him that I was going to write an article about his paper, and he was kind enough to share the following piece of advice with me, which I now share with you:
“One thing to notice: the more you swap pairs, the more you will notice everything else that is a problem in your environment. Make sure you have good team support, good retros, and that you take the time to do the little engineering polishing tasks. Things like automating formatting (thus also making it 100% consistent), unifying IDE, and eliminating requirements to code review are important supporting practices for most teams. If you leave those friction points in, you will notice them more and more and eventually blame the pairing. So make sure you fix the frictions!”
