Collective Intelligence with Mob Programming
I returned on May 2nd from the first ever Mob Programming conference in Cambridge, MA.
Many people from around the world (US, England, Finland, Denmark, France, Africa, China, India) gathered to learn from Woody Zuill, Llewellyn Falco, Maaret Pyhäjärvi and others about a relatively new phenomenon in the IT world – that of groups interacting in the same (head) space to maximize the (coding) results while using the collective intelligence of those present.
The premise of mob programming or ‘mobbing’ as it is sometimes called, is that people will learn together how to ’turn up the good’ in the team and in each other to the benefit their customers. The result is less time spent churning, estimating, waiting for answers, deciphering someone else’s code, fixing bugs. The greatest possible intelligence is collected into the code in a focussed and collaborative manner with the whole team (analysts, testers, programmers, and other specialists, as needed). When paired with solid tests, written first, this technique is a great way to produce high quality software that is more easily maintained. It operates more like a great team of scullers on the Charles River than a traditional IT shop.
What happens in the majority of organizations that produce software is that most code writing is done by individuals using different styles at different times, at different desks, without much consultation – yet with the hope that the disparate parts will be able to be integrated. In the status quo organization, there is not much attention paid to the ecosystem that the code ‘lives in’. Sometimes people are moved from team to team like chess pieces for short term gains. Teams are treated as temporary constructs. The resulting software may appear cracked in places, and mis-understood, poorly formed in stressful situations.
If one developer wrote it and no one else understands it, the future ability to modify such code will be diminished. Therefore, the best way to have great code now and in the future is to put many minds at the same task, at the same time, in the same room (virtually or physically). The likelihood is higher that the best ideas from people will emerge and be used when people collaborate this way.
I got to experience this first hand myself. I took part in a small group of coders who had to code the solution to a small problem together. Only one person ’the driver’ is allowed at the keyboard at a time and this person is not allowed to type anything other than what others in the room agree to have them type. The screen is projected so that everyone can see. All ideas and code must be verbally expressed and transmitted to the person in the ‘driver’s’ seat. The first time we did this, we had one designated navigator – who could direct the driver. The driver stays in the driver seat for a very short time – perhaps 5 to 15 minutes, after which the person who was driving can become a navigator and contribute again to the ideation about what to work on next, taking input from the others. I very much enjoyed learning and participating in this, and certainly felt there was no hesitation in people sharing their ignorance or their knowledge. Everyone learned. In the conference setting, there were numerous opportunities to do this at beginning, intermediate, and advanced levels. The beginners used simple coding katas, and even some ‘koan’ lessons for learning to code in a new language. Everyone had fun.
We also used simulations using other tools to teach about mobbing. One group, that I participated in briefly, produced an article for InfoQ as a mob, writing together in a very short time. Another group used the card game ‘Set’ (which was invented by Llewelyn’s mother) to simulate a mob session for solving the puzzle. Done in several rounds, once with a single navigator, then later with no single navigator (giving directions), it clearly shows how messy it can get -when first starting out – to have a group of people giving directions all at once. But I observed that the time constraints work well in combination with a self-organizing team. The team learns best with trial and error how to moderate itself and inquire of each other before directing the ‘driver’ to take action. In fact, after each change in the driver, we held a mini retrospective: each person contributed their ‘aha’, or passed. Mobbing groups are encouraged to experiment. Some teams are even working this way when not co-located, using video and screen sharing software. As others have pointed out, great teams develop implicit and/or explicit protocols – you can read more about such teams here.
Whether with coding, or with non-coding simulations, the best individual performance on a challenge is almost never as good as the performance of a team of possibly less ‘able’ individuals. I took this lesson away at a wonderful simulation activity at Amplify Your Effectiveness conference in 2010. We compared the performance of individuals at estimating ten ‘Guinness Book of World Records’ to the performance of teams that worked on the same challenge together. We observed that it is never the team with the best individual scorer that wins the team competition, even with the same 10 records repeated.
I am quite sure that I experience both peaks and troughs in my productivity throughout the day. I would be thrilled to be able to lean on other teammates and vice versa to ideate and produce the best possible products and deliverables. If only managers could give up a fixation on ‘time spent’ on code, in favor of frequent delivery of valuable code for the business, I bet they would experiment with Mob Programming and find it very beneficial. And ‘valuable means too that it will be more easily maintained in the future – it won’t only be the tech lead who makes decisions and knows the history of the code’s back-alleys. It will be collectively understood.
Finally, as you will read from Woody’s writings, and from his talks on mob programming, this technique should never be something anyone can or should mandate. Teams should be left to choose their best way of working and be encouraged to experiment with their collective intelligence.
I really appreciated the people who travelled from afar to talk about and practice the principles of mob programming and I would definitely attend this conference a second time.
If you need a facilitator to help you get started, please reach out to me. If you wish to read more about Mob Programming, you can read Woody’s book and Llewellyn’s books here and here and watch the time lapse of a day in the life of a team that mob programs. On May 18th, I’ll be giving a workshop on The Core Protocols (another great team productivity enhancer) with an open discussion about mob programming at the end. These two ways of working and interacting are quite awesome for the audacious and courageous self-organizing teams. If you are in DC, you can RSVP here. You do not have to be a woman to attend.
A last note: at the end of the conference, I offered up the idea of creating a community book about teams that are coding using the Mob Programming principles. It would involve interview questions and answers about the teams’ experiences, perhaps modeled along the lines of the Who Is Using Clean Language, Anyway? book. (That book is itself modeled after Who is Agile? book that I helped edit years ago). I would need a co-author and a couple of teams to volunteer for interviews to get started. It would evolve as a Leanpub book until we had a great cross section of teams from around the world representing different domains and challenges, perhaps 20 or 25 teams. If you are interested, please leave me a note below or contact me via Twitter at @andreachiou.
Connections and Congruence 
Leave a Reply