Mob programming - 5 developers on a single computer?!

Running experiments to improve our processes is part of our daily work. So when I hear about something that might help us improve, I want to investigate it. At the start of 2019, I joined the Domain Driven Design Europe convention. During the breaks, I chatted a lot with other participants, mostly developers.

In many of these conversations, the workshop Mob Programming from the convention a year earlier came up. The developers were really, really enthusiastic about mob programming: multiple developers working in the same room on a single PC. They explained how much they had learned and grown as a team as a result of these sessions. That was a clear signal for me to learn more about it. After that, I decided we would experiment with it.

A vital part of an experiment is the hypothesis. Without it, you don't know if the experiment succeeded. My theory was that mob programming would help us share knowledge between developers while building clean code.

I planned and prepared our first mob programming session, which wasn't that hard:

• Get a computer hooked up to a big screen
• Place a table in front of the screen.
• Add five seats to the table.
• Put some snacks and supplies on the table.

And there we were, five developers in a room with just one computer:

What happened during our first mob programming session?

Wesley sits down near the keyboard (we're using his PC) and is automatically assigned the role of driver. The driver is an intelligent input device: he can type but is not allowed to make decisions. The other developers get the role of navigator. They are the ones discussing what should happen and tell the driver what to do.

The driver is an intelligent input device: he can type but is not allowed to make decisions

We start working on a simple warming up story where we have to remove some outdated content in the footer of the site.

The navigators tell Wesley to start Docker. We immediately see an error message. Wesley explains this sometimes happens, but it’s always fixed with a couple of retries. We don't retry, but the navigators explain which settings to change. From now on, Docker always starts without an error. 

Wesley writes on a sticky note what he learned about Docker. He puts this sticky note on the large sheet of paper called Learnings.

I write on a sticky note that Docker not starting was holding us back. I feed it to the Waste Snake, a large sheet of paper with a snake drawn on it. On this sheet, you put sticky notes describing everything that holds the mob back from actual programming:

After 12 minutes, a buzzer sounds. Everybody has to shift right. The driver becomes a navigator, and one of the navigators becomes the driver. It's a bit of a hassle, and it takes some time to get started again. But we get a lot better at it after a couple of switches.

We finish the story and start working on the next one: Yii2 view causes bogus comments in HTML, which causes HTML invalidation. An interesting story. It was already picked up twice by different developers, but they both got stuck. Everybody chips in with the story. Eventually, we fix the issue in a way everyone is very pleased with.

After two hours, the session ends.

What did we learn from our first mob programming session?

We do a retrospective meeting to discuss what went well and what we can improve on. The key take-away is: we fixed the story better / more thoroughly in one iteration than when a single person would have worked on it.

We fixed the story better / more thoroughly in one iteration than when a single person would have worked on it.

Everybody feels energized during the retrospective. We all liked the experiment. It becomes apparent that mob programming indeed helps us share knowledge while building clean code.

Most learnings were quite obvious, like when a shortcut was unknown to the driver, or configuring tools to help you more efficiently. It became obvious how easy it is to add waste to your own development process by using workarounds if a system behaves unexpectedly. This validates the need to embrace the Improvement Kata.

Other learnings were more subtle. For example, finding ways to split a difficult problem into smaller problems. Or the suggestions on how to really work Test Driven by first creating a failing test instead of just adding a test afterwards.

The experiment succeeded! The next session is immediately planned

One of the more challenging things to get right was the level of communication between navigators and the driver. You don't want to spell everything out, especially for the more experienced developers. But you also don't want to let a more junior developer feel like he's thrown in at the deep end. Over time, the mob learns how to address individual drivers the right way.

Remote mob programming

In the Netherlands, we're currently in a lockdown. Our office is closed, and everybody works remotely. This makes mob programming as described above impossible because we can't be in the same room.

However, we still wanted to do mob programming sessions. Through trial and error, we came up with the following for an excellent remote mob programming session:

• Everybody has a webcam, and everybody turns it on during a session.
• We use Whereby to host our meetings because you can share your screen and still see each other's camera feeds.
• The driver logs in on a dedicated computer through a remote desktop connection (we created a mob user account on the internal network for this).
• We created a separate mob user account for Git. This makes it very easy to switch roles.

How can I experiment with this in my own working environment?

Of all the articles, blogs, and e-books I read on mob programming, I can strongly advise reading these two:

• The Mob Programming Guidebook (recently renamed to Ensemble Programming Guidebook) by Maaret Pyhäjärvi.
• Mob Programming - A Whole Team Approach by Woody Zuill.

After that, just pick a date with your team and try it out. Enjoy!