What is mob programming?

Mob programming is a radically different way to approach building software as a team. Rather than focusing on each developer maintaining their own parallel work stream. It brings a group of people together to focus on delivering a single task.

At its core this may sound like wasted effort. If there are 4 people in the team they could potentially have 4 pieces of work being actively developed, surely that would be faster. The short answer is no, which makes the obvious next question “why?”

It’s because rather than focusing on work in progress we’re minimising queuing time. In a typical development process there are several points where the developer is waiting in someone else’s queue. Do you need help from someone? Do you need a code review before you can complete your task? if you do then you’re in the queue. What do you do while you’re in the queue? You pick up something else. This is either context switching to a new task or proceeding with the current task making an assumption that when you get to the top of your colleagues queue you wont need to make changes.

Let’s play out the code review:

• You finish some work, create a PR and assign it to your colleague C.
• C is busy so it goes into C’s queue
• You start something new.
• C finishes their work and picks up your review. They see some changes they’d like made and let you know it’s done
• You finish the other task, assign a second review to C
• You address the work on the first review assign it back to C
• … so on

It’s this sort of queue build up, constant context switching and waiting, that mob programming seeks to address. Mob programming is all about making sure you have the right people in the room to eliminate queue time. A mob is able to take a task from kickoff all they way through to merging in one steady line. The kickoff is done as soon as the team is ready because everyone who needs to be there is already in the mob. There is no waiting for code review, the team has been actively working together and effectively reviewing the code as they go along. When the task is complete they are able to merge the code and move onto the next task. We have minimised context switching and all but eliminated queue time.

How does it work

The guides for mob programming set out two roles.

• The Driver: Plays the role of the Human Machine Interface. Their role is to be the typist. The difficult part of this role is that the driver is not allowed to add their own understanding into the picture. They are just doing what they’re told to do by the navigators.
• The Navigators: The navigators are everyone else in the mob. The navigators are busily researching and understanding the problem so that they can direct the driver to the best solution. The difficult part of being a navigator is that in order to get your idea to happen you have to be able to explain it to the driver. The navigator will be tempted to take control and just type in what they want to see. That must be avoided. This ensures that there is at least two people who have some understanding of any changes that are being made.

In order to ensure that everyone is involved the driver role is rotated through the team quickly. Historically when teams were co-located the driver role was rotated every 3-5 minutes. In remote teams the change over tends to be more costly so 10 to 20 minutes is a more common cadence for remote mobs.

Inevitably the navigators will come up with multiple ideas that are not able to be worked on simultaneously there are two strategies that come into play to address this.

• Most junior idea wins. When there are multiple competing ideas the mob should follow the idea expressed by the most junior team member first. This maximises the learning and helps to grow the junior members.
• Follow an intent through to completion. When a team member has expressed an intent (aka that they would like to try a solution) the team then takes that on and follows it through to completion. Stopping half way through because someone (almost certainly a senior) can see an issue robs the rest of the team of the learning gained from following it through.

These two strategies help the team to practice active experimentation and adopt a built measure learn mindset rather than getting stuck in analysis paralysis as people argue for their optimal solution while nothing gets done.

How we’re doing it

All of that is how the guides suggest that you do mob programming. Now I want to talk about how Media Experience has been practicing it.

We have split the team into two concurrent steams of 4 or 5 people the green stream and the yellow stream. Members are allocated randomly to each stream at the start of the sprint. A decision is made after the allocation about where any work being carried over from the pervious sprint should go.

These initial allocations are a suggestion and a starting point so we can ensure that everyone has a chance to work with everyone else on the team. That said mob programming is all about having the right people in the room, so if someone is needed or passionate about the work being done in the other stream they’re free to move between streams.

Each stream has two dedicated blocks mob blocks per day. 2 hours in the morning and 2 hours in the afternoon. These meetings are set up in the shared calendar so everyone in the team is able to access them quickly and easily. If someone is not able to make the meeting the mob is able to continue without them.

During these sessions we have adopted the driver and navigator roles as set out above. We’re rotating the driver role typically every 15-20 minutes. We track the time using the timer app in Zoom. The driver uses their development environment and shares their screen. At the end of their session the driver commits their code to the repository and the next driver pulls it down.

We tried using VS Code live share to share the control and make the change overs faster. We found that this made it easy for a non driver to “just show you what I mean” and circumvent the mobbing process. Regularly committing the code helps to ensure that the mob is able to progress independent of any member. We have experimented with mob cli (link) to expiate the handovers but have found that the complexity introduced by the tool didn’t improve the handover process.

How’s it going?

We’ve been at this for a couple of months now so it’s reasonable to ask how’s it going? What have we learned? My view of how the team is going is that overall it’s good.

What’s working?

I feel more connected to the team. Being on a call while working on things gives us a chance to have the conversations about things that are not work. During the times where we’re getting started, the down time during and handover or build we have more of those side conversations that have been lost in the world of remote working.

Along with those “non work” conversations have found that I have seen more instances of serendipitous alignment where team mates have found that they can jam on an idea. This has played out in team mates working together on 20% time projects.

These small positive interactions are important for maintaining a good working relationship with your colleagues. Studies have found that high performing teams have a ratio of 5 positive interactions to each negative interaction. Given that we have plenty of needed negative feedback interactions (e.g. requests on PRs and pushback in sparring sessions) these small positive interactions during downtime in the mob become incredibly valuable.

I have also seen an increase in the quality of solutions built by the team. We have all experienced those times where we open a pull request and decide that asking for major re-work is not worth it. When mob programming these discussions happen when it’s easy to change direction. The team is able to build software that meets a higher quality bar because they are constantly refactoring as they go. The team can fulfil the idea that “if you cant explain your solution you probably don’t have the best one”. With mob programming you’re always explaining your solution, so the code is easier to understand and easy to understand code is less error prone.

I have been impressed to see that although we made a major change to our processes we did not see our sprint velocity dip. I think this is because we are seeing the can drop the amount of time any piece of work spends in a queue. This is the PR, and help needed queues mentioned above but also the individual has been taken away from the work queue. On any given day we all have too many things to do. We’re in meetings, prepping upcoming work and more and more we’re expected to interview… a lot. During all of these things our work sits idly in our queue while we’re working on something else. With mob programming one member missing does not stop the mob. With 4 to 5 people in each stream the work is able to continue a pace while a stream member is otherwise engaged.

What’s Challenging?

This continual progress leads into the fact that any process change isn’t without its challenges. Something I wasn’t ready for was the feeling of missing out when the work that I had been putting effort into progressed without me when I was drawn into other meetings. It’s great to see the tasks being finished off but it’s an odd feeling.

I’ve also found that not all voices are equal, as much as we try to follow the advice of taking the most junior ideas we can only follow these ideas when they’re put forward. It can be hard to put forward ideas when louder people are constantly thinking out loud. This phenomenon is particularly obvious as the size of the mob grows.

It is important to shape a mob well. Mob programming talks about ensuring that the needed expertise in in the room. I have found that 9 developer with similar skillsets do not appear to generate better results than 4 and vastly increase the chances that a small percentage of participants will dominate the discussion.

If there are multiple streams that are interconnected or require access to the same person/resource in this case the streams may need to converge. This leads to larger mobs and the problems mentioned previously.

Caveat

This overview of how mob programming is going within Media Experience is my view of the world. I know not everyone in the team has enjoyed the process as much as I have. I don’t feel that I am the right person to speak to their experiences.

Should your team try?

Closing off this post. Do I think your team should try mob programming. Yes. I think it’s a net benefit to the team. You need to be prepared to give it a good try, find where the rough edges are for your team and work to improve them.

If you do that I think your team will be more productive, build better code (DFTC) , feel more engaged, with the work and also with the rest of the a team (BWHB, PAAT).

Honestly I now think that mob programming is the best way to do remote software development.

Resources

Woody Zuil’s talks on Mob Programming

• Mob Programming and the Power of Flow • Woody Zuill • GOTO 2019
• Mob Programming: A Whole Team Approach • Woody Zuill • GOTO 2017

Remote mob programming

• Remote Mob Programming

Praise to criticism ratio

• The Workplace: The Ideal Praise-to-Criticism Ratio
• Feedback and the Power of the 5:1 Ratio