Promiscuous Pairing: Do it often, do it fast and learn from it
blog.semantikoz.com
blog.semantikoz.com
Pairing on everything is a disruptive waste of both programmers time, unless one programmer is hugely less experienced - in which case, it's not pair programming, it's coaching, and coaching is a different skill set that you can't expect everyone to either WANT to do or to be any good at.
Pairing on all design / analysis spikes is just about bearable, and maybe there are benefits to having everyone switch around spikes quickly.
It obviously doesn't work well for you, so I strongly recommend not doing it.
Why is it so terrible that people are playing with interesting, creative, sometimes crazy new ideas, and sharing their results?
It's more the happy-clappy tone of these articles that grates than the fact the someone's done it and written about it. As someone else pointed out, the experiments are never controlled, never peer-reviewed, and often unreproduceable, but they're always presented as the next great thing to hit software development. It's time to stop with the bullshit, stop with the certified courses, stop with the pretence that if only your team pushed bits of paper around a whiteboard they'll magically become 10 times more productive. Instead, find out how each individual can be the best developer they can be, and facilitate THAT. Of course, that requires investing in actual people management, which is something that is in short supply compared to agile-methodologies-du-jour.
However, I've also seen situations where two junior devs have produced some appalling edifice of code between them, so perhaps that's an argument for rotating pairs faster. Personally I feel both they and the company would have better off if they'd been coached by someone with more experience, but that's not pairing, the power relationship isn't equal.
It was brilliant. Great fun. Energising. Hugely productive. Especially when I was the most experienced person on the pair.
I don't understand Arlo Belshee's emphasis on the lack of flow in this setup in his original paper. Personally I've found the combination of good pairing + TDD to be a recipe for getting into flow very quickly. It seems designed to produce those little nuggets of problem/reward that suck you in and keep you grinding away.
The practice certainly hasn't worked for everybody (check out Mitch Lacey's try at using it for example http://www.mitchlacey.com/resources/adventures-in-promiscuou...) - but having tried it once I would be keen to try it again and try and figure out the contexts that are causing it to work/fail.
The experimentation that led to Promiscuous Pairing was certainly based on the practical. It was not scientific; it was process engineering. We had no goal to make a great discovery. Rather, we had to ship software RTFN, so we were optimizing our process to do so.
The company board had told us that they were liquidating the company if we didn't have 2 signed letters of intent at the end of the trade show on May 25. We started the project in October, using a traditional development approach (what we'd been doing for the last 2 years).
On Jan 15 or so, I got the group together and asked. 100% of the engineers agreed we had a <5% chance of even having a sales demo ready for the trade show. We were guaranteed not to have enough to get a sale.
So we were desperate and had, literally, nothing to lose (and no time to lose it in).
That was why we were so extreme. We measured the outputs that mattered to us (defects, long refactorings, output), and we reviewed our process each iteration. We did 1-week iterations (industry, as we learned later, was doing 3-4 weeks at the time). We continually developed qualitative heuristics and used our quantitative numbers to filter them on viability. We needed to know what would work faster than any quantitative approach could tell us.
And then we just tried all sorts of stuff. As we got more useful heuristics, they encouraged us to try more bizarre stuff. One of those heuristics was that learning was king: rate of progress == rate of invention == rate of learning stuff (techniques, domain knowledge, ideas that others on the team had).
That was what led us to try the very short pair swap times.
In the end, we stayed with them only because they worked. And man did they work.
5 years later, Ward & Jim convinced me to write up the experience for Agile 2005. Then a couple of other teams tried it.
Interestingly, many of them had exactly the same direct effects from the practice as we did - and those direct effects led to project failure, rather than success (Mitch's team & paper is a fine example).
On the basis of that, my current assumption is that you should only use PP if you're good at removing roadblocks and are already pretty low friction. PP makes all problems glaringly obvious all at once, and gives you the info & learning to address them. But if you can't address them quickly enough (or if there are too many friction points) it just destroys morale and productivity.
I now think of this as a 400-level practice.
First learn to pair (this takes time - it's a set of skills). Do stuff to improve feedback. Shrink all your cycles (we were shipping software 2x per day and hit 100% of our 1-week, 2-week, and 3-month commitments before we tried PP). Once you have eliminated that friction (we did it by fiat, since we were basically being laid off otherwise), then PP can be an awe-inspiring tool.
And... this is an experience report. Their "experiments" weren't controlled, blinded, or anything like that. So there are almost certainly contextual nuances that haven't been discovered yet. What worked for Arlo's team won't necessarily work for your team.
And... this is true of nearly all software development techniques. There are hardly any controlled, blinded studies of software development techniques that are worth a damn. So if Arlo's technique seems intriguing, try it. Just don't (a)hold it up as proven technique, because it's not, or (b)get angry that it's not scientifically proven, because chances are very, very good that none of the software development practices you love have been scientifically proven either.
PS: An interesting followup experience report from a team at Microsoft that tried promiscuous pairing for a while: http://dl.acm.org/citation.cfm?id=1155480.
That said, it certainly depends a lot on context. My team at work has tried full on switch-every-ninety-minutes Promiscuous Pairing a couple of times. Once, it worked really well: everyone started knowing the code much better; we got more done; we spent less time stuck and confused and more time producing quality software. Another time, it was a nightmare: everyone felt rushed and confused; it seemed like we were constantly being interrupted; we never felt like we were getting anything done.
I'm not entirely sure what made the difference. Our going explanation is that, the second time around, we had a higher baseline level of interruptions already, so the constant switching just added stress and made it impossible to focus. We haven't tried switching that aggressively since then (although we've been considering it lately, as the circumstances seem better for it--that's why it's on my mind right now). On the other hand, it's still rare for us to switch less than once a day, and that's been absolutely great.
Also, this sounds very similar to the benefits I see when running code retreats, http://coderetreat.org/. Though the problem domain doesn't change throughout the day at a code retreat, its interesting to watch the diffusion of ideas and knowledge.