They say the first thing to drop on the floor when a team tries any Agile methodology is pairing. The opposing arguments tend to go like this:
Old-School Manager: “Why is everybody going so slow? Why is it that I’m using twice as many people to get half the work done?”
Agile Cheerleader: “You have to consider what else you’re gaining. By pairing, you will get higher quality code with fewer defects. You’ll also increase adherence to team standards because pairing is like real-time code review. And on top of all that, you’re reducing key-man risk by spreading knowledge. So in reality, over the long haul your project is going to be much faster.”
Old-School Manager: “Ok, yeah I guess that makes sense.”
But odds are, the first time the project misses a high-level milestone, or otherwise starts to feel behind to the Old-School Manager, pairing will go right out the door. Either as an edict from the manger, or (I think more likely) as a disease that starts to catch on among the developers. As pressure increases to get more work done, each will feel like “golly, if I’m pairing with Joe to get his cards done, then I’m not getting my cards done. How does that make me look?”
The problem is that even though most rational people, when thinking rationally, will see that pairing increases the throughput of a project, in a local (ie. developer-by-developer) sense it feels slower. And people are emotional beings so feelings count for a lot.