Mob Programming: not as crazy as it sounds

Thanks to Agile Singapore I saw Woody Zuill speak about mob programming yesterday.

I'd been sceptical about mob programming at first, probably because I'd only heard the term and a one-line description of it rather than hearing from the main proponent of it himself.

The "mob" is not quite the whole team, the "mob" is all the right people being in the right place, at the right time, and working on the same problem on the same computer.  As it happens, that is also what a whole team should be: all the right people.  So, you do not need extra programmers, but you do need the people who know the requirements, understand the system, know how to test it, and sufficient to program it.

What's perhaps more interesting is that mob programming just evolved naturally out of the environment that Woody had cultivated - it was the right thing that needed to be done at that time and it was the right team.

What seeds had been planted to cultivate this environment?

For a start the team was used to working together on problems.  There were weekly study sessions, weekly coding dojo practice sessions.

The team was focused on getting better by effectively using retrospectives so that they could produce better results.

The team - the team of professionals - was also trusted to be able to decide for itself how best to work on something.

Mob programming then began when the team got together to re-familiarise itself with a project and its horrible code base.  Then they just started working on it together.  Then they just carried on, working together on one problem at a time.

Like pair programming, mob programming has a driver-navigator relationship, but in mob programming there is one driver and many navigators.  The programmer as the driver in a pair (or mob) is a "smart input device".  (This is unlike my first experience of pair programming when everything wrong was done, resulting in me acting as a typist for my partner without any thinking going on in my head.)


Mob programming also makes various problems just disappear.

Communication is not a problem when you have all the right people together in the same place at the same time.  The same goes for decision making and meetings.  Thrashing is also eliminated as one problem is completed at a time.

Having the whole team with the same attitude to quality acts as a barrier to the introduction of technical debt, so too does having the whole team understanding the system and working on one problem at the same time rather than producing dissimilar solutions to similar problems.

So mob programming is not as crazy as it sounds, but for it to work you need to have cultivated the right environment, which is not a bad thing to do anyway.