Mob Programming

I first saw this video of Mob Programming a couple of years back. Mob Programming is pair programming taken one step further, the whole team is based around a single machine. The developers rotate regularly and those who are not driving can add feedback, make suggestions or simply watch and learn. Everyone should be placed on a level playing field. I will admit to being highly sceptical of Mob Programming at first.

I advocate walking skeletons to ensure we are on the "right path" when developing. We wanted to do these as a team, during our planning and tasking phase. I suggested mobbing rather than watching a solo developer on a projector and it turned out to be quite fun. We also learned a few new tricks such as keyboard shortcuts or IDE techniques along the way.

There were a few rough edges, mainly due to the setup used. A laptop around a screen proved difficult and this in turned seemed to put pressure on individuals. In repeat sessions we have used a dedicated space, with a proper machine and large screen or projector. The ten minute rotation is enough to allow focus, while not being too long between switching.

While Mob Programming is a relatively new experience for myself, it is proving quite valuable as technique to help develop a walking skeleton. Currently we have not used Mob Programming for full time development. As it stands, I would find it hard to recommend this for some development tasks. Additionally I can think of developers and managers that would simply resist any suggestion of mob programming. Unfortunately for some teams this may be too much of a hard sell.

The end result of a mobbing session is a task board filled up with minor tasks such as improving test coverage, refactoring, or edge cases. The core functionality is delivered as a team. Combined with the walking skeleton Mob Programming solves some of the key problems that traditional tasking and planning introduces and is well worth an experiment.