Mob Programming: Is It Just a Fad?
I first heard the term Mob Programming on a Hanselminutes podcast. I then got a closer look at it through Mark Pearl’s talk on the subject at an Agile Auckland Meetup. He even wrote a Leanpub book about Mob Programming. Mark is an Engineering Lead at MYOB and it’s great to hear him share his first-hand experience with running a mob team locally. I like the potential of Mob Programming but I’ve been pondering for the past week: Is it just a fad?
While I have not tried Mob Programming, I experienced Pair Programming at a Code Retreat and finally understood the appeal of collaborative coding. I have subsequently failed to get more people at my workplace to adopt it. Everyone agrees with the concept as if it’s a utopian ideal that ‘good' teams subscribe to, but is impractical in the ‘real world'. I believe those same reasons will prevent mass adoption of Mob Programming.
Realistically, only a small subset of development teams will be able to pull this off. Hence, I’ve started thinking about the attributes that mob members must possess. I don’t see this as a checklist. Rather, each attribute is on a scale and the likelihood of success increases when more members sit on the mature end of the range.
Consider this list the ramblings of an uninformed man. They have not been empirically validated and I invite you to challenge me in the comments section. I may update this list as I grow and read more:
- Relatively young team: I am referring to the age of the team as opposed to individual team members (although that will have a factor as well). Younger teams are more open to new practices, while older teams are more set in their ways. I am not immune – I have caught myself getting defensive when a colleague suggests a different way of doing something. Changing practices that have worked well is a tough ask.
- Crave feedback: Some people are ‘open to feedback' - they will receive your comments but then vigorously defend their own ideas. I am describing a more extreme version where you actively invite and enjoy constructive feedback. This is such an important quality to possess as mob programming is feedback-centric. It’s not going to succeed if members are stressed out and defensive going into a mob. I wished I could say I craved feedback, but I’m working on minimising my ego when I get code reviewed.
- Empathic communicator: Closely related to craving feedback is the ability to give them. Good communication requires many sub-skills and the one I’ve chosen to highlight is empathy. When you have 3 or 4 chefs in the kitchen and only one cook, it’s important that each chef is given the opportunity to infuse the dish with their magic ingredient. I have worked with people who sit somewhere on the autism spectrum and they sometimes miss social cues. They railroad the discussion and it escalates into an us vs. them battle, as opposed to compromising. They may need to be actively managed so that they don’t dominate the conversation, or conversely, feel that they are not being heard.
Those are just some of the soft skills I think a good mob programming team requires. I have not mentioned a single technical skill or process as they are just the icing on a cake made up of those foundational abilities. However, a couple of questions came up during Mark’s talk that he concedes are common questions. They were:
- How do you convince management that 4 programmers working on 1 problem at a time is better/cheaper/faster than 4 people working on 4 different problems?
- How is individual performance appraised when work is completed collectively?
Unfortunately, I don’t think his answers are convincing enough to allay management’s fears about adopting mob programming. A good advice I learnt from Tim Ferriss' The 4-Hour Workweek is that it is easier to ask for forgiveness than ask for permission. This may be one of those times where a development team just needs to sneak in mob programming and demonstrate the results at the end.
I will attempt to answer my own question: I think Mob Programming is a long-lived fad. It’s going to be around for a long time just like Pair Programming has: Well-acknowledged but poorly-adopted. Which is quite a shame.
Photo credit: hans s via VisualHunt.com / CC BY-ND