Pair or mob programming has been the buzz word for a while in development. The notion that two or more heads produce better thinking than one is appealing. You also get automatic competence transfer among team members, when at least one more person has insight into the code written.
All relevant arguments, that I can get behind. However, for this to work as the main approach and method of working, it requires a group of compatible personalities. Compatible with the method in itself as well as with each other.
In my experience, pair programming is efficient in specific situations. When you’re stuck, or doing something completely new, or when you do code-review in pairs. But it’s nothing I can do all day, every day. I get tired, headaches, and self-conscious to the point where my brain locks and can’t type or think at all. Several colleagues and friends express the same experiences.
I’ve heard that it’s just a matter of getting used to it. That everyone will and anyone can get used to it, and the team will prosper. This, however, is something I can’t get behind.
Pair programming is an outright energy drainer for some combinations of introverted personalities. Such fundamental personality traits are unlikely to change or be prone to work arounds.
But it goes beyond mere introversion vs. extraversion. The people involved need to be prestigeless and not worried about their status in the group, or focused on getting their way. They need to be sensitive and open to other people’s point of view and expertise, while at the same time not get stressed out by constant scrutiny.
So things are not as easy as to just tell your programmers to pair/mob program, and your efficiency will skyrocket. On the contrary, it might render some programmers completely paralysed, or cause unnecessary conflict in the group, not to mention frustration and fatigue.
Successful pair/mob programming requires a delicate and complex pairing of personality types and competences that might give you the effects you are after.
The evangelists of pair/mob programming, the guys who travel the world and lecture about this, are often starts of their field. They can pick and choose team members as they please and see fit. A reality few team coaches and project managers live in. The evangelists can, after all, shape reality to fit their methods and processes. Of course mob programming will work wonders for them! Of course they’ll have great results to show! If a team member doesn’t fit the mob, they’re out.
But what about when you have to shape your method and process after the team, the group of people – individuals – that you are assigned? Creating the best possibility for each individual is after all the reality most of us have to work with. To find the best way for this set of individuals to work efficiently together, without a bunch of dogma.
Surly, that is how you build a team rather than a mob!