Mob and pair programming have been buzz words for a while in development. The notion that two or more heads produce better thinking than one is appealing. You get automatic competence transfer among team members, with at least one more person has insight into the code written.
All relevant arguments, that I can get behind. However, for mob programming to work as a main method of working, it requires a group of compatible personalities. Compatible with the method in itself and compatible with each other.
In my experience, pair programming is efficient in specific situations. When you’re stuck or doing something completely new. But for me it’s not something I can do all day, every day. I get tired, headaches, and self-conscious to the point where my brain locks down. I can’t type or think at all. Several colleagues and friends express the same experience.
I’ve heard it’s 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 personality types, caused by fundamental personality traits that 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 the benefits of the practice, 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 practices to fit 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?
For further reading on personality types and software teams, please see my post MBTI and Software Developers.