Reflections on six months of mobbing
The Guv’nors team (responsible for the Data Masker and Data Catalog products) has been mobbing extensively — in fact almost exclusively — for the past six months. This has proven particularly useful as the team have undergone significant personnel changes during this same time. By focusing on mobbing, the team has been able to successfully offboard three engineers and onboard two while continuing to deliver frequent customer value.
Wait, what is mob programming again?
Mob programming is a software development paradigm in which “the whole team works on the same thing, at the same time, in the same space, and at the same computer”. It’s a scaled-up pair programming technique where the whole team has a laser-like focus on a single critical task. For more information on mob programming, we’d recommend reading “Tackling SQL Prompt’s Parser with Mob Programming” and “… something on Mob Programming with Woody Zuill”.
Initial hurdles
When the team first starting experimenting with mob programming, we ran into several core problems. To begin with, we used a strict Randori kata approach to mob programming. This involved a single navigator directing the driver, while the rest of the team observed. Everyone then rotated positions every 5–10 minutes. This technique can be useful for training the mind to not immediately jump in with ideas. However, we often found both the navigator and driver didn’t know the best route to take and so progress was slow. We were also using mob programming as a way of exploring a new, unfamiliar codebase, so without a singular focus we were quite fragmented. This led to work that one navigator/driver pair had done being needlessly thrown away in favor of trying something new, just for the sake of it.
We also struggled with a significant knowledge imbalance in the team, which led to the dreaded ‘programming theatre’. This is where a single engineer dominates the mob because they know the codebase better than everyone else. Instead, we wanted to allow less experienced team members to learn by trying. There’s nothing inherently bad about one person leading a piece of work. They just need to communicate their thought processes clearly. They’re responsible for levelling up everyone else and keeping them on the same page. Programming theatre can lead to observers feeling disengaged, disempowered and just “along for the ride”. Here, we found no quick fixes. We just kept practicing and reminding each other to continue to mob the next day. We also encouraged the expert to take a background seat and to mostly observe, only jumping in when needed to unblock people.
Mob programming is a skill. You need to practice it to become better.
One of the biggest perceived disadvantages is that we’d move faster if we worked alone. This leads to a reluctance to try mob programming for anything that isn’t a large complex task.
Just as you would not try to learn a new programming language by building a large complex machine learning algorithm, why would you learn to do mob programming on a really complex task? That is setting you up for failure.
It’s much easier to see the benefits of mob programming on something small and then scale it up once you have honed your skills.
Key success points
After practicing mob programming over the last six months, we’ve seen several big benefits. Mob programming is a brilliant way of onboarding new team members into unfamiliar code bases and new technologies. For instance, our two most recent starters had no prior experience with React. Now they both feel confident to lead the development work on UI-focused tasks!
As we’ve all adjusted to working from home, we know that we all are going to have an off day every now and then. We found mob programming useful here. The comradery of building software together allows the team to continue to move forward even when team members are not at their best. There is also a lot to be said about the morale boost that comes from seeing work moving across the board quickly!
We’ve been moving faster than if we’d been working individually. This may sound counter-intuitive, but we’ve noticed that working this way allows us to work in a very lean approach. For instance, code review happens in-line during the engineering process. This reduces handover time and leads to higher quality code. Without planning to, we have caught ourselves practically using trunk-based development as we can merge our code to main right away.
Managing git is so much easier when you only have main and the singular feature branch the team is working on.
Another side effect is the knowledge sharing that happens naturally during mobbing. This significantly reduces single points of failure, levelling up the team. As an example, our domain expert on Data Masking is away on sabbatical for six weeks and although we miss him sorely, we have still managed to consistently deliver value!
We are also much better boy scouts! By working as a mob, we can fix adjacent issues (e.g. usability bugs) without going through a formal planning process. For instance, while tackling some technical debt, we discovered some usability/design debt. If we had been working solo, we likely would not have addressed these issues as they were not the core focus of our task. However, working as a mob, we could decide — then and there — to just do it, making the product better as a result! We even drafted our designer into the mob to aid with said improvements.
Stuff that we have discovered, learned and practiced
Initially the whole affair was very business like. However, after practicing we found it to be a good way to spend time together and lower the barrier of speaking.
One other win was that it forced us to slice tasks as small as possible. This way we could take breaks after finishing a chunk. That said, we have also used work-in-progress tasks a lot as we realized we don’t need to complete a task before taking a break. So long as it’s in a good enough state to continue, it’s fine to take a break. This ‘good enough state’ is easier to achieve, knowing the entire team is going to return to it in a short period of time.
Commit often. We’re frequently switching control from one person to another. The person driving checks out the code and shares their screen in their own environment. When it’s time to pass control to the next person they commit, push the code and the cycle repeats.
Every time someone joins the mob (even if they’ve only been gone for 10 minutes), we do a short recap of where we are. This both keeps the mob on track and gets the joiner up to speed.
We found, it’s more efficient to keep the mob going and do trivial tasks together rather than break the mob apart. This is because there’s always a ramp-up time, before the mob can get into a flow.
Stuff that we decided not to mob on
There are some tasks we felt were not worth mobbing on. Mind-numbing formatting changes or other tasks requiring zero innovation are done individually between mobbing sessions.
Stuff that we have decided to mob on
We have mobbed on pretty-much everything else! Obviously, engineering tasks are our main focus but we’ve also worked on documentation, support and research calls. We even mobbed this very article! This way it’s not just software development knowledge getting shared, but we also leveled up our writing and communication skills!
Is mobbing the right thing for your team?
That’s something you’ll have to find out for yourselves. The important thing is to try it out and not give up at the first hurdle. We have found it takes lots of practice and a good dose of patience. In our experience though, it’s so worth it and we’ll continue to mob extensively going forward!
