The past week we started at Rangespan a new pairing model based on the experience at Silver Platter described in the research paper ‘Promiscuous Pairing and Beginner’s Mind‘. Let me first introduce the traditional flow model and compare it to promiscuous pairing before I give some feedback from my experience.
The paper provides compelling insight in an alternative mode of pairing to optimize learning and spread of knowledge through fast switching. This is an alternative to the traditional idea of flow where the intent is to achieve full immersion in a task. In programming this commonly includes an internalised understanding of the goal, dependencies to the task, and how to achieve it. This is even harder to achieve in a paired situation. The highly productive flow, however, requires a deep knowledge of the current task and its context, which is time consuming and necessitates a person or pair to focus on a task for a long period of time. As a result persons specialise and that reduces the spread of knowledge. Consequently only a small amount of talent and experiences get exposed to the task, which may lead to a suboptimal solution.
The proposed alternative is promiscuous paring, which stipulates that partners and tasks change frequently throughout a day. This prevents a state of flow and (deliberately) forces the new pair members in a ‘Beginner’s Mind‘. A beginner to a new task has no preconception of the supposedly optimal solution and thus is more likely to approach a problem creatively. The beginner experiments because she has no idea of the ideal or traditional solution to a problem. Hopefully, she will do this with eagerness and curiosity as well as the preparedness to fail and learn. This comes easier to someone new to a task than to someone who faced it before. This leads to innovative solutions, motivated team members and a rapid spread of knowledge, patterns and best practices. Something that usually is almost mutually exclusive. You either foster best practices or innovation. Furthermore, the different talents in a team are more likely to be exposed to problems and no one pair which possibly lacks a talent to solve a (sub-)task gets bogged down with a problem.
We started this Monday by pairing for 90 minutes, which according to the paper is the ideal time before the beginner’s mind settles and gains taper off. Our pairs consist of a master who worked on a ticket in the iteration before and a (new) student. They work together on the task/ticket until the 90 minutes are over. The master then moves on to be a student in another pair while the student becomes the master for the current task/ticket and is joined by a new student. This way a hard problem or long task is not stuck with one pair and everyone gets exposed to it.
After one week of promiscuous pairing I consider it very useful for new team members like myself. It exposed me to many parts of the product, which I otherwise would not have seen. It gives the opportunity to test drive others’ tools and setups which helps tremendously when you are new to a language and framework. Moreover, it allows you to be productive since you can take part in solving the underlying problem at hand decoupled from the language and framework that would normally stop you. This combines nicely with subsequent implementation of the solution together, learning useful patterns and idiosyncrasies by example.
There are some side effects to this pairing mode that need consideration. Creative work is harder since you have little time left to go off on a tangent, explore long-term oriented ideas or do some blue-sky digging. This may need some dedicated time. While the pairing does not take the whole workday meetings and auxiliary tasks often enough eat up the remaining time. Another point of reflection at the moment is the length of the iterations. For some tasks a longer pairing may improve productivity. We may try variations the coming week. I am wondering if this is a similar case as with Test Driven Development where a short term gain comes at a long term expense or if some specialisation is just in the nature of growing software engineering teams and should be account for in promiscuous pairing by allowing some iterations to be longer. On the other hand, a specialist/talented individual does spend three hours over two iterations (first student then master) on a task.