The Hidden Magic of Mobbing
The often unknown benefits of mob programming
Mob Programming has some really obvious benefits. I’m a fan of mob programming and have been actively practicing it for years. In those years, I’ve found two layers of magic that mob programming delivers.
There’s the first layer
These are the things that usually come up when discussing mob programming.
- Consistent coding
- Knowledge transfer disappears.
- Encourages sharing of skills to create T shaped individuals
And then there’s the subtle stuff
The things that don’t come up as often. They’re gold, absolute solid gold, but for some reason they don’t get pinned to the mob programming conversation. I’ll break a few of them down for you.
Onboarding new team members
When you’ve got a new starter, it can be a difficult learning exercise. If there is an existing codebase, they have a lot of reading ahead of them. If there isn’t, there’s a ton of product domain to understand. If the team is established, they’re gonna have tools, conventions, languages, practices and principles that will need to be understood. This typically takes the form of shadowing, but what about mobbing?
I witnessed this first hand, a little over a month ago. A new individual joined our team and on day one, he was writing code as the driver of the mob. Yesterday he was fine tuning one of our applications using load tests that the mob had put together using Gatling. The team guaranteed that when new facts appeared, he was present for them. They encouraged him to learn by doing. No dense documentation, dull meetings or 30 slide presentations. Just generating value at a pace he was comfortable with.
Forming a team
Mob programming is often described as a “mature engineering practice”. I think this is a fallacy. Anyone can do it, with a little coaching. Moreover, I think new teams should do it, a lot. When starting a new endeavour, teams need to establish how they want to work. Choosing languages and frameworks needs full team buy in. What better way than to choose it together? Then when you’re working on your brand new product, you’ll feel the pain of your decisions together. This unified experience of engineering creates a bond that is at the base of all high performing teams.
Maintain flow and facilitate agility
Some of you will have heard of the phrase “Work in Progress”, often abbreviated to WIP. Engineers and agile coaches often obsess over this metric because of how crippling it can be. The more WIP you have, the longer it will take to get things done. This is intuitive. If you start ten things at the same time, it will take you longer to get all ten done than it will to get one of those things done.
To combat this, teams often introduce “WIP Limits” to their boards. These ensure that no more than N tasks are started at once. WIP Limits are a useful tool but they often are a blunt instrument for a complex issue.
When teams work individually, they often increase their work in progress. A five person team might have five tasks in flight at once. This increases the risk of merge conflicts, but it impacts flow too. If something happens during the sprint, you have a huge amount of WIP that needs to be closed off or reverted before you go to something new. That’s a lot of wasted effort. So what if you mob?
Everyone works their way through one thing at one time. Flow remains nice and even, with one item in progress at a time. An even flow enables teams to pivot quickly and, should things change halfway through your sprint, you’re not stuck with 5 undone tasks. It also doesn’t suffer from the simplicity of a hard WIP limit. If a task is large or complex, the team work on it longer. If it’s small, the team will likely get through it quickly. The WIP constraint flexes to the pace the team can set. That is the essence of agility.
I ramble about technology regularly on twitter.