(I'm the author of the original paper. So take my ramblings here with a grain of salt.)
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.
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.