The other day I heard Woody Zuill – an Agile Coach at Hunter Industries in San Diego, US – speak about “mob programming”. At first, the simpleton in me thought this meant writing code dressed in fancy suits, wearing shady hats and stylish sunglasses … Woody corrected this presumption fairly swiftly: “mob programming” involves having about 5 developers share one computer and collaborate on writing code.

The main principle behind mob programming isn’t completely new;  there’s the concept of pair programming whereby two developers work together on a single computer. One person will act as the ‘driver’ and writes the code, whilst the other people review each line of code as it gets written and ‘navigate’ the person who’s coding.

One could say that with “mob programming”, the number of people involved in pair programming has simply been cranked up a bit. I quickly learned that there’s more to it:

1. Working together on a single task at a time – The basic concept of mob programming is that you’ve got a team working as a team together on one task at a time. The team will have one keyboard and one screen (perhaps supported by additional screens just so that everyone can see what’s going on).
2. Real-time collaboration – The area where I can see mob programming potentially breaking down is the active involvement of the entire team. I can imagine that with a team of 5 developers, some of them might not feel particularly engaged and might start ‘floundering’ a bit as a result. With pair programming this is less of a risk since there just two people sitting next to each other. Also, I can imagine that with mob programming the main task of a dedicated  “navigator” is to ensure that people get a chance to give their feedback and stay involved.
3. Everyone in the same place at the same time – Ideally, it wouldn’t just be developers forming part of the ‘mob’. If done in a structured way, I can see mob programming working really well if for example product planning and design is done in the same room. Having a UX person, a QA tester and/or a product person in the same room as the developers (as they’re writing code) could be very helpful in terms of removing noise and getting direct feedback.

Main learning point: I guess the thing that I find most appealing about “mob programming” is the collaborative aspect of it. The idea of having a team of people in a room working on the same thing can – if executed well – really help in achieving efficiencies and cross-functional input. Mob programming might not be appropriate for a simple bug fix, but I can definitely see its value when kicking off a new product or when experimenting with new technologies. Feedback and engagement around a particular project/product will be real-time as opposed to operating in silos or having long feedback loops.

Fig. 1 – “Mob Programming, A Whole Team Approach” (talk by Woody Zuill at Oredev Conference 2013)

Fig. 2 – A Day of Mob Programming by Woody Zuill

Related links for further learning:

1. http://mobprogramming.org/
2. http://zuill.us/WoodyZuill/
3. http://mobprogramming.org/mob-programming-basics/
4. http://codebetter.com/marcushammarberg/2013/08/06/mob-programming/
5. http://startupproduct.com/mob-programming-comes-to-twitter-a-startup-product-talks-sfbay-meetup/
6. http://en.wikipedia.org/wiki/Pair_programming
7. http://www.extremeprogramming.org/rules/pair.html
8. http://llewellynfalco.blogspot.co.uk/