Willing spontaneous pairing

jam sessionOne of the most debated and debatable XP practices is Pair Programming. Here is what I found to work best for me: willing spontaneous pairing (to carry on Arlo Belshee‘s wonderfully ambiguous ‘Promiscuous Pairing‘).
This means I don’t pair all the time. Mostly because
  • my working hours don’t line up exactly with those of my teammates. I am an early riser. That means in the morning I am usually already in the middle of something when my colleagues come in and I consequently leave before they do in the evening.
  • when I am working on a task that seems obvious to me, I feel too driven, when someone is sitting next to me and I end up making bad choices in a hurry. This happens when typing is actually the limiting factor and I am feeling like I am wasting my pair partner’s time.

But I am still very willing to pair in general and I do appreciate the advantages of it.

will·ing /ˈwiliNG/


  1. Ready, eager, or prepared to do something.
  2. Given or done readily: “willing obedience”.

That means whenever I feel like I could use a second opinion on something like a design decision, I will readily ask one of my teammates to pair with me. And on the other hand, when one of them is asking me to pair with him or her I am eager to do so.

I try to let the pairing happen spontaneously, i.e. before getting stuck with a problem.

spon·ta·ne·ous /spänˈtānēəs/


  1. Performed or occurring without premeditation or external stimulus: “spontaneous applause”.
  2. (of a person) Having a natural, and uninhibited manner.

I try to avoid spending too much time pondering a hard problem on my own. Be it a difficult design decision or a gnarly bug I just can’t figure out how to fix. When I do ask one of my colleagues to help me with something, I ask them to finish whatever they are working on right that moment or at least, get to a point, where they can pick it up easily again after they paired with me. With this, I hope to minimize the interrupting nature of my request.

These pairing sessions can last anything from minutes to days. Sometimes I just need my pair partner to be my rubber duck and I already get to the solution while I am explaining what I did so far to get to where I am and go ahead implement it on my own. Other times it might take longer to figure it out and we decide to implement it together.

Before asking someone to pair with me, I mentally structure the explanation part of getting them up to speed with what I am working on at the moment and the problem I am facing. Many times I end up doing some refactoring during that process.

I do believe that pairing actually leads to different and most likely better solutions than programming on your own. My assumption is that by practicing willing spontaneous pairing, I still get some, if not most of this benefit.

With this approach, I am hoping to mitigate the downsides of pairing while still reaping its benefits. Like everything else pairing is a trade-off and I don’t think it’s helpful to be dogmatic about it.


One comment

  1. Manuel,

    Excellent article! I call this practice “casual pairing,”, but I also don’t like getting caught up on nomenclature, and I like your name for it!

    You have exactly described what I have described to people. Some might call this “common sense — of course we sit and help each other from time to time.” Yes, you do, but many developers* are subconsciously afraid of the practice, or just don’t think about doing it. By giving it a name and some context, we as coaches can encourage the practice and keep it more in the conscious mind of the developer and give it more acceptance so that developers won’t be afraid to do it.

    * When I say ‘developers’ here, I’m referring to the Scrum definition(programmers, testers, BA’s, UI designers, etc)

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 )

Facebook photo

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

Connecting to %s