Let us start a thread about Pairing constraints. I do constraints as ways of improving the quality of Pairs over time. But most of them reduce the productivity of the pair during the short period you apply them. That is a feature, you are focusing on the pair. https://twitter.com/maaretp/status/1156665494398799872

let's get the obvious one out of the way: the first pairing constraint I ever tried was "Strong Style Pairing" (I think I learned it reading @WoodyZuill) most people know that one: your idea cannot become code by your hand: the person giving the idea is the navigator for it.

(the strong style pairing is powerful, you get faster to that point where you understand each other, at least understanding problems get exposed a little quicker. Also it is a constraint you could just adopt forever.)

another classic: the silent pair
the pair programs for a fixed amount of time communicating only through code, no talking
it helps to do some ping pong pairing here (switch drivers are every red test) I think silent pairing works better with katas than real day tasks

you probably know these two already let's move to answering your question with the ones I created myself:

serial scratch implementations: List the ideas you are comparing without judging them, see if you can find another one even if stupid that would still solve the problem, spend a timed 15 minutes implementing each idea in the list, discuss afterwards

(the serial scratch implementations thing helps devs quit the loop of arguing too long about their idea being the best one to do right now)

Mini-retrospectives: each 30 minutes or so, you stop for 5 minutes to discuss what is working for you or not in the pair/current way of working together and what you would like to try so that the next 30 minutes could maybe be better

(Mini-retrospectives seem extreme but I do them with mobs and pairs all the time, I also do them in my trainings, they can change the way you are working in real time quite drastically over the course of a day it is AWESOME)

the ariadne's thread: start with a piece of paper, every time you debate/disagree pause, jot down the options you have, circle the one you have chosen, draw an arrow from that one to the next one you note using this system, you end up with a map of your discussions & decisions

(the ariadne's thread seems silly but the mere fact of noting this down on paper changes the dynamic of tha pair a lot, visualising what you have discussed and decided also changes it, it reduces friction in many cases)

the blind pair: a strong style pair where the navigators keep their eyes closed and does not have the right to see neither the driver nor the screen at all and we switch driver navigator every 10 minutes (should be done at least so each person is driver and navigator twice)

(ok the blind pair sounds weird but it requires people to improve how they say things a lot, if you do it a lot it will make remote pairings much easier , heck after doing it some times with @XDetant we got to the point where we could pair while he cooked) https://twitter.com/malk_zameth/status/1033117805393137664

The meta-communicating pair: for a fixed (say 1h) period of time : every time a person says something the other will rephrase what was understood in their own words
each time something your pair says makes you feel something you pause not that and talk about that feeling

The evil pair (also evil mob by taking two secret random people in the mob) one of the pairs will try to sabotage the production in ways that are not obvious (like they where trying to avoid being seen as saboteurs)

(the evil pair, or evil mob, is a good exercise of resilience, most sabotaging people will come with will be things that happen in real life due to tiredness or ignorance or something else and that irritate pairs in real life, so practicing handling them in a safe space is good)

What I usually do to create a constraint is to look for ways to make something that is difficult become more difficult in order for it to no longer be bearable and people to need to stop and figure out ways to solve it so that when they go back to a normal level of it: they can

it boils down to the work one would do in accessibility: anything that improves accessibility improves the lives of all: if you do a ramp for people in wheelchairs it benefits anyone else (carrying groceries, moving heavy objects, with a broken leg, with a baby stroller etc)

Similarly if you make your work situation artificially hindered : the solutions you will find to solve that hinderance will be useful when you take the hinderance away

forgot a good one!
The Pokémon : for 45+ Minutes every person in the room can only say a single phrase. I usually use the phrase “I’m
Very good at this” but the phrase don’t matter just That it is the only thing that can come out of the mouth of anyone in the pair/mob

(The Pokémon explores the richness of tone, gaze, non verbal communication and other forms of communication in pair
People tend to exaggerate them a lot so it works and then practice how to do them better in pair/mob it is interesting to do just after or before silent pair)

Also very important!!! I never employ those constraints (except mini rétro) in pairs that are not working at all, where people are already irritated with each other or things like that
Adding hinderances requires safety and consent
Much like pair programming itself requires them