TheCodeCleaner
Jun 7 · 4 min read

We’re now approaching half way through the year, in a team established in January. When we started, we used mobbing as a way to learn new domains and spread knowledge around the team, but also as a way to keep a laser-like focus and (deliberately) minimise work in progress.

Copyright 2019 David Legge

New Year Beginnings

The first month was around investigating the risks inherent in a new project, and establish technical feasibility. We assumed, or at least I did, that once we had done that the need and will to mob would dissipate, giving way to pairing (and heaven forbid) solo work.

This hasn’t really happened. There has been some pairing work going on occasionally, but equally the team has tended to ‘flock together’ onto single problems.

My colleague Mark Jordan blogged about those early days.

Online Mobbing

One driver of this has been the ease of online mobbing.

Early on we used a meeting room which had a monitor in front of each side of a horseshoe. This was great, but required moving up there after you’d managed to find a free time and book it.

Whilst I always envisaged pairing to be physically at the same computer, once you get more than that at one machine it can become difficult for everyone to see properly. Even two people at a computer can be a challenge, and that’s why I always have a second keyboard and mouse on my desk.

The team has very often just set up a call in our messaging app and everyone joins— I’ll allow you to guess what software we use, though other vendors are available (but not as good, frankly). Someone shares their screen in the call and we mob together.

As someone who has quite a few meetings to go to (so my team don’t have to), being able to join in on an ad hoc basis is helpful.

Driver Rotation and the Pomodoro Technique

Whilst the call is ongoing (it has on occasion been initiated at 9.30am and only been ended at 5) anyone’s screen can be shared and so the ‘driver’ can be rotated.

We’ve also introduced the Pomodoro technique to ensure the driver’s role is rotated frequently. There are simple online tools for this, but one time when we forgot to start it, I just drew a clock on the screen with the ‘crayon’.

Crayons

What’s really good in our messaging app is all the observers are able to draw in ‘crayon’ (which quickly fades away) on the presenters screen to highlight things — underline, draw an arrow; show agreement — draw a tick; signify it’s time for a brew (tea, coffee, whatever’s your poison) — draw a mug or teacup; all without interrupting the flow. If you’re waiting for a build and are really quick, you can manage a game of noughts and crosses!

The Strong Pairing Rule

There’s a rule that can be used in Pairing, or Mobbing, that says that the driver can only make changes that the Navigator(s) have suggested, and not do anything themselves directly.

I can see many circumstances when this might be a useful rule; with an overly dominant character say, or perhaps deliberate practice when getting used to Mobbing (or Pairing); but we just have not found it necessary. As long as you are rotating the driver and the Mob is working as a team, this has been fine.

#NoBranches

Another advantage of having the team Mob on everything, you effectively eliminate the need to branch. Other than a branch to move ‘work in progress’ from one developer’s machine to another — to swap driver for instance. If these are less than a day’s work, you’re as good as Trunk Based Developing.

With so many pairs of eyes on it, do you need a formal review?

Mob Refactoring

I’ve run sessions at two conferences over the last year, Agile Cambridge (with Willem van den Ende (@MostAlive on twitter), and Agile Manchester (by myself), with the title Mob Refactoring Live.

The sessions have focused on refactoring an ‘unhealthy’ codebase, let’s say; and have had really good engagement from people trying out Mobbing. As well as developers who’ve enjoyed the experience, we had a number of non-developers come along and see the process — of both Mobbing and Refactoring.

And yes, we refactored the code as a group, discussing the problems, how we might solve it, and a volunteer driver (duly rotated) making the changes on a large screen.

Conclusion

Mobbing is great for the exact reasons some people don’t like it.

Work in Progress is minimised, so the team is not working on ‘all the things’ at once.

“if you have more than three priorities, you have no priorities” — Jim Collins

This keeps the team really focused on the most important thing to be done.

It also means the team has to be just that — a team, not a group of individuals hoarding different bits of knowledge and expertise. Forming a hive-mind. Keeping each other honest, disciplined about design and tests, discussing design decisions, code style and good practice.

And just as importantly, the team is getting to know each other, forming as a social unit.

As a manager once reiterated, Scrum is called Scrum because it’s supposed to be about the whole team working together to push things over the line. Mobbing is about doing just that.

Try it — you might like it.

Ingeniously Simple

How Redgate build ingeniously simple products, from inception to delivery.

TheCodeCleaner

Written by

@TheCodeCleaner agile consultant, committed clean coder, slayer of complexity and harbinger of tea. Remourner. Now 'part of the team' at @RedGateProdDev

Ingeniously Simple

How Redgate build ingeniously simple products, from inception to delivery.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade