The Way of the Mob

At SVTi we always think about how we can work better together and exploring new ways of doing so. This time we felt it was time to do a serious attempt with Mob Programming so we invited the evangelist Woody Zuill for a training workshop where he neatly and pedagogically led us through the process mixed with practice.

The method has been described as “pair programming on steroids” – a catchy phrase but we found it to be something quite different.

In short mob programming is about getting  a whole team, developers, testers, UX, design, product owner and managers together solving problems as a team.

How is it done?

It’s best described on Woody’s blog or in his book so I won’t go into details, but it is nicely summarized in the quote:

“All the brilliant people, working on the same thing, at the same time, in the same space, and at the same computer”

In short:

  • Everyone is gathered around one (large) screen, one (fast) computer and one keyboard
  • One person is appointed driver whose task is to be a superintelligent input device but who shall not take initiatives on her own
  • One or all of the others are navigators steering the development, whether it is coding tests, UI, backend, refactoring or whatever
  • Roles are rotating so a new driver is appointed every 20-isch minutes
  • Navigation can be about new features, tests, UI, backend, refactoring or whatever
  • If someone gone or need to go to a meeting the mob can work on

Woody helped us through the sessions, and being a solid experienced developer, reminded us of good practices like red-green-refactor, TDD and clean code etc. on the way.

Is it really efficient?

The main doubt before the workshop was: Is it really efficient? How can it be? Using six keyboards must be faster than using one?   

These are relevant questions in terms of lines of code but we felt the gains relates more to other types of goals. And we found many up-sides we didn’t think about:

  • Waiting time and hand-overs are reduced – as all stakeholders are present and can answer questions and contribute on the spot
  • Quality is part of the process – easy to keep focus on clean code, TDD, refactoring,…  
  • Saves time – if everyone works together, do you need daily and planning?
  • Focus is inevitable – both by sitting together working on the same task but also as you have to turn off notifications while working together
  • Great for learning – this may be the most important benefit, learning from peers, how you can do things, patterns, etc. but also by gaining understanding for different roles

Is there a downside?

We haven’t used it long enough to see all possible problems but one Woody mentioned is that not everyone feel comfortable working together all the time. Some people might have to take a break from the mob.

Prestige and getting stuck discussing details might be the most obvious mob killer. Agreeing on some sort of Code of Conduct could be helping in that case.

In the teams who tried we also saw that sometimes it works better moving back to practice mode i.e. only having one navigator.

What now?

More and more teams are trying it out and we are setting up more mob stations and hopefully we’re getting better at it practicing and trying new models.

It might not be the answer for all work, all team or all people but we believe that more often than you expect, this may be the best way to work – and it is also great fun solving things together and a great way to get to know each other better.