Promiscuous Pairing: Do it often, do it fast and learn from it 7

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.

7 thoughts on “Promiscuous Pairing: Do it often, do it fast and learn from it

  1. Reply andy Mar 26,2012 03:24

    your PDF link returns to the blog post instead of getting the PDF

  2. Reply James Brechtel Mar 26,2012 03:50

    “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”

    Could you expound on what you mean by this?

    • Reply Christian Mar 26,2012 22:45

      Hi James,
      I meant to express that in TDD cutting corners may let you finish a feature faster. On the long run the lack of tests probably will cost you more (time|money) than you saved cutting them in the first place (i.e. regression).

  3. Reply Adam Mar 26,2012 05:26


    I would like to hear more about the logistics of this. How do you manage the schedules, the tasks/projects, location, timing etc.?

    Are the tasks time sensitive at all, or are the “training tasks”?

    I’m looking into some ways to immerse multiple new people into the job at my office; this could be a nice experiment.

  4. Reply George Dinwiddie Mar 26,2012 07:56

    I’m not sure why you call this the opposite of flow. I’ve certainly found I can get into flow, while pairing, in less than 90 minutes.

    Of course, that doesn’t happen in every pairing session. Pair programming is harder than it might seem. I find it helps to, as I’m working, express my thoughts out loud so the other person can share them. This often makes me very self-conscious at first.

    With some people, it’s harder to find a common rhythm, also. I don’t know why that is.

    Another thing I find helpful is to break the work into very small but functional slices. If you do so, you can get several of these done in 90 minutes. This seems to promote a sense of flow over choosing a bigger piece of work and not seeing the progress. Defining these smaller slices are part of the conversation between the pair.

  5. Reply Jon Stewart Mar 26,2012 11:52

    Hi Christian,

    I was on the Silver Platter team. I think you’ve already gotten a good taste of the strengths and weaknesses of promiscuous pairing. It’s _awesome_ at getting folks up to speed and maintaining the shared hive mind, even at high velocity. After my first two weeks, I was contributing nicely to the team.

    However, it is mentally exhausting. XP advocates the 40hr workweek, partially because XP is taxing… making things promiscuous means you should have a 32hr workweek. Obviously, that’s not tenable (or salable), but I’d suggest tweaking things a bit as you go. Maybe have four days of pairing and one day of useful solo work? We did find that there are some tasks that don’t demand a pair, like profiling, improving some IT stuff, exploratory coding, etc. Pair programming tends to force each coder to be task-oriented… a little downtime is not a bad thing and allows the creative juices to flow.

    The other thing to consider is that sometimes you do need an expert on a task. At SP I once worked on several tasks that involved creating a collision detection system for an Asteroids-style game. The problem was that I was usually in the “master” role for the pair, but I sucked at calculus. So, I created an okay system with nice interfaces, and it passed unit tests, but it was definitely buggy and things only got better when I swapped off and my Harvey Mudd-educated colleagues swapped in. Don’t be afraid to put the right person on the task, especially when it’s tricksy.



Leave a Reply




This site uses Akismet to reduce spam. Learn how your comment data is processed.