The following is a recap of our findings doing Mob Programming for the past 6+ months in an in-house dev team, what we’ve learned and gained from the process.
Our team includes two devs which have been in the company for 5+ years. They were bottlenecks when it came to working on some of the company’s legacy systems and systems which require deep domain knowledge.
At the time, we’d grown our team from three to five developers within two months, which opened up the question: “What’s our on-boarding strategy?”
Mob Programming looked like a great way to:
- get to know the new guys
- assess their skills
- introduce them to our solutions, architectures and infrastructures
- get the old guys to share their knowledge with the rest of us
During our sprint reviews, we decided upon the following changes to the Mob Programming paradigms to match our team.
Driver rotation time
We started off with a 10 minute driver rotation, which turned out to be too long when you’re 4+ developers. Being a navigator for 30 min. or more made us lose focus due to passitivity. This was particularly true when a team member’s knowledge about the subject matter being worked on was low.
After cutting the rotation down to 5 minutes focus was somewhat improved.
Even with the reduced rotation time, a five people mob often felt too large. This was in part due to the office space available — we were crowding a regular workstation which made it hard just following the code being written on screen — and in part due to a feeling of time being wasted by being too many people on the same task.
We cut the mob size down to 2-3 people, essentially ending with a setup more akin to Pair Programming.
Note: The feeling that our velocity was suffering was never substantiated statistically, but having team members feel that they’re wasting their time is bad for morale and hence we chose to act upon it.
After two weeks of Mob Programming, we decided to choose which tasks were suitable for the entire team to collaborate on, instead of defaulting to everyone working on the same task.
We found the following tasks to be particularly suited for Mob Programming:
- Project startup and initial architectural decisions.
- Tasks with a low bus factor.
We found the following tasks to be particularly unsuited for Mob Programming:
- Learning the basics of new frameworks.
- Lengthy debugging sessions.
In essence, tasks which don’t show progress for an extended period of time were draining morale. This isn’t a surprise, since these tasks are taxing even when working alone, but when doing Mob Programming the drainage felt amplified; some bug hunts seemed like endless time sinks, with only one or two members of the team being able to contribute in a meaningful way.
We work 2 or 3 devs per task, unless the task is deemed relevant for everyone on the team. Whether a task is “Mob Programming worthy” is decided during backlog grooming.
We do driver rotation every 5 min. when working 3 or more devs and 10 min. when working as a pair.
We take breaks from the code and each other when needed. It took some time, but now everyone on the team is comfortable saying “I need to work on my own for an hour or two, let’s pick this up after lunch” without anyone having hard feelings about it.
Return on investment
Our new team members were working at full capacity within a month, which is some of the fastest I’ve had the pleasure of witnessing.
Some of the benefits we’ve reaped from Mob Programming include:
- Improved social interactions.
- Great knowledge sharing – from keyboard shortcuts to architectural patterns and everything in between.
- Code reviews, all day every day.
- Reduced bus factor on business critical legacy systems.
- Collective code ownership.
- Constantly challenging/improving/enforcing company best practices.
I’ve found Mob/Pair Programming to be the most effective mentoring tool I’ve come across. Had I been using it earlier in my career, I would have been alerted to the challenges of some of my mentees a lot earlier, and would have been able to react accordingly in a more timely fashion.