What is Mob programming?
In a nutshell, Mob programming is a software development methodology that takes pair programming to the next level. How?
Well, Mob programming is all about collaboration: the entire team gathers around one computer/laptop/workstation and works on a problem together. One person, “the driver”, sits at the keyboard and writes code while the rest of the group is observing or navigating, telling the driver what to do next and reviewing each line of code. The driver has no power to make any decisions; they can only type in what has been agreed by the group.
Team members switch roles frequently – when the timer goes off, the next person in the group becomes the driver, while the previous driver joins “the mob” and participates in the decision-making process.
Setup for Mob programming
To start a Mob session, have everybody assembled in a room with a big TV or a projector and a couple of desks facing the screen. I’d recommend everybody bring their laptops, but leave them closed in a designated space to avoid distractions. Take your laptop only when it’s your turn to be the driver. Then, choose the topic, set the timer, and you’re all set!
If you are using multiple laptops, don’t worry about commit messages – a fluent workflow is more important than a complete Git history since the handover points are bound by time, not by implementation state.
Mob programming sessions at Matmatch
We are using a 15-minute timer as a necessary break. Do not underestimate how intense Mob programming sessions could be. We usually get pretty exhausted after just a couple of hours! But at the end of the day, it all depends on people in your team and their preferences – you’ll have to choose what works best for you.
We usually swap computers when the driver changes. I think it’s important for everybody to have their preferred development environment, so sharing a single computer is not something that worked well for us.
To get real value from our Mob programming sessions, we chose to work on creative ideas from the backlog, rather than working on day-to-day routine tasks. Later I’ll explain why we’re selecting more experimental tasks and what we gain from that.
What I’ve learned the hard way: always come to meetings prepared. Mob programming sessions are no exception. If the topic was not chosen beforehand, you can easily waste half of your precious Mob time discussing what to do. That’s why we created a Slack channel for brainstorming ideas and a wiki page to hold a record of previous and upcoming topics. At the beginning of every Mob session, we usually do a quick vote on the open topics and the most popular one wins.
Just a word of warning: be very specific in the scope. Don’t try to tackle problems that are too big. It’s quite easy to overestimate what you can do in a given time, and any problem can easily set you back an hour or two. It’s discouraging to fail getting things done, so make sure you pick a problem that could be resolved within one Mob session.
If possible, define milestones in advance. Then you can set a more ambitious scope as a long-term goal – great if you can make it, but if not you still have plenty to show off afterwards.
Presentation of results
Do good and speak about it! Mob session format is not so common, so there might be people in your company that would question or criticise what you’re doing. Educate the rest of the organisation and mitigate comments like “it’s a waste of time”, “you’re playing around” and “no good for the company” by presenting what you’ve achieved!
We also had a good experience inviting people from other departments to our Mob sessions so they could contribute something to the topic we were working on that day. The end result? They were always happy to bring value to the session and had a lot of fun with us!
Why are we investing time in Mob sessions?
Running a Mob programming session serves multiple purposes at once and the benefits are can vary per session. Here are four key benefits of Mob programming sessions:
Every engineer, no matter how experienced s/he is, brings some unique set of knowledge, experience, and skills to the table. By watching how somebody works (for example, how their workspace is set up, which tooling they use and how they get things done), we can quickly share that knowledge and profit from our diverse skill sets.
Also important is the fact that we are ignoring artificial boundaries like “front-end”, “back-end” and “devops”, Mob sessions are great for learning how other people deal with the same problem. Plus, it’s inspiring to research things and show some cool new tricks to your team during the next session.
A group of people can’t immediately start being productive together. Every team goes through different stages of group development. I personally believe that a group development process is never really complete, especially in our dynamic economy where people come and go in ever shorter cycles. I think that teams are immutable – every person leaving or joining the team alters the group dynamic, and the process starts anew.
Mob sessions help to form a special bond – as a team, you go through something together and you achieve something together. The work in “the mob” speeds up the forming process and brings a lot of things to the daylight. After the Mob session, you can clearly see what kind of people you’re working with, what their preferences and communication styles are. You also get to know what bothers them and what drives them.
This knowledge is beneficial for our daily work, where communication is often asynchronous, delayed and in written form without feedback.
Deliver something cool for the business
With Mob programming sessions, you never know what expect in the end – sometimes you develop a small productivity tool that makes daily life easier, sometimes it’s an eye-catching feature for the product itself!
Prepare to be surprised to see what happens when you allow developers to be creative and to take part in the product process. In fact, a lot of Matmatch’s “highlight features” have their origins in Mob programming sessions. Mob sessions allow us to take up an idea and turn it into reality – before anybody can overthink and kill it. It helps us get people excited about ideas.
Experiment in a safe space
Rumor has it that experience is what you get shortly after you need it the most. In today’s world, where technology is changing faster than you can read introductory blog posts, engineers need a safe space for experimentation.
To be frank, if you do not provide that space, engineers will do their experiments on the central product (and this is something you want to avoid). Like in science, some experiments fail, some yield great results. These results afterwards benefit the product development cycles because we learned which technologies to leverage for certain tasks, and which ones to avoid.
Most of our latest technological advances over the last few months like server-side rendering and use of “serverless”/function as a Service Architecture were pre-tested in Mob sessions! And afterwards, we felt comfortable using them in production.
Mob Programming sessions are not only fun – they serve us in a variety of ways, and we are very happy with the results we are getting. We have been doing them for half a year now and will continue doing them weekly for a long time to come! Maybe you should too?
Do you have any additional questions or want to join in on the fun? Get in touch with me at firstname.lastname@example.org
Chris also did a 🇩🇪 German Podcast Episode about this topic, check it out: uhl-steine-scherben.org