What on earth is “mob programming”!?

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/

3 responses to “What on earth is “mob programming”!?”

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: