“All the brilliant minds working together on the same thing, at the same time, in the same space, and at the same computer” 

Woody Zuill

What is Mob Programming

Mob Programming is when three or more people work at a single computer to solve a problem together. It is about leveraging distributed knowledge when programming.

Distributed knowledge is all of the knowledge that a group of people possess and might apply in solving a problem—Mob Programming brings those people together and puts them in front of a single computer.

Mob Programming is a software development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer.

It is not only applicable to coding, the team also can work together to do almost anything a typical software development team tackles, such as defining stories, designing, testing, deploying… Almost all work can be handled as “working meetings” or workshops, and all the people involved in creating the software are considered to be team members, including the customer/product owner.

«Gather together people with all the needed skills and knowledge»

Benefits of Mob Programming

With Mob Programming, you and your team can produce quality software, at a steady rate, with a low dependency on specific individuals.

At its core, Mob Programming is flow centric—you optimize flow efficiency (things to get features finished quicker) instead of esource efficiency (getting them done cheaper).

You also get fewer key-person dependencies. When people work on their own, they become the expert on what they’re working on. With time, the organization becomes dependent on them. When you work as a mob, you build redundancy into the group. Having more than one person know how to do things means the impact on the organization when someone is no longer around is significantly reduced.

Mob Programming also helps upskill the less experienced people in your team at an accelerated rate. When you work as a mob, the team can share ideas with one another. As the sharing continues, the knowledge of the team grows, making everyone more effective and efficient.

In a feature branch-based workflow, you are blocked waiting for the code review of your pull request. While waiting, you start another feature and need to switch context. In a mob session, we have continuous and implicit code reviews – no feature branches, no waiting, no context switches.

Groups are better at making decisions and solving complex problems.

The mob minimizes the technical debt. With our wealth of know-how, experience, and opinions to discuss, we are able to
make well-founded decisions everyone agrees with. When we are coding, we all agree on changes and code style. As a consequence, we don’t need code reviews or pull requests.

Mob programming reinforces Team building.

Having a group working together on one thing leads to increased quality. Multiple people reviewing the code as it’s being written results in fewer defects getting to production. Detecting and avoiding defects early on saves money because you have fewer support calls, bug fixes, emergency patches, and so on. Not to mention, fewer defects in production also leads to happier clients.

Learn from the Team

Sharing knowledge is at the heart of Mob Programming. Everything the mob does is the result of in-depth discussions. Nothing is done without agreeing on the why. That’s where everybody learns.

We get better by learning from each other. Because the whole teams works on everything together, we’re always on the same level of knowledge and have a bus factor of the size of the team. We benefit from our different backgrounds and perspectives.

With Mob Programming, onboarding only takes weeks, not years.

Driver/Navigators

Mob Programming is not 1 person coding, 5 people watching.

Mob programming is not about getting the most output of each individual, is about of getting the best of each of us into everything we do.

There is a Driver (this concept comes from Pair Programming) and everybody else in the team are Navigators.

Some protocols must be put in place to avoid everybody talking at the same time or to avoid skipping from one idea to another one.

Basic idea of Driver/Navigator (aka Strong Pairing) is we have a driver at the keyboard putting the ideas that the team wants to have into the computer. Everybody else in the team is a navigator. Navigators are talking about what they want to do, sharing their ideas, guiding the person at the keyboard.

«For an idea to go from someone’s head into the computer it must go through someone else’s hands»

Llewellyn Falco

This allows the team to collaborate, instead of just watching someone programming.

Driver: Smart Input Operator

The Driver is also known as the typist. Driver’s job is to act as Smart Input Operator. Driver can take instructions from others at a very high level, liberating the team to focus on the right stuff.

The Driver is not the programmer, he is just a smart assistant, taking what the rest of the mob is asking them to do and implementing it.

Conceptually the driver can be considered as an extension of the computer and not part of the team. Having person at the keyboard as just input operator helps avoiding that flow of ideas is blocked; what would happen easier if the person at the keyboard participates sharing his ideas.

The Driver allows the rest of the mob to focus on solving the problem. He must not code on his own. This balances the participation of all team
members and it reduces the dominance of strong characters.

To be effective, Driver needs to:

• Understand what the rest of the mob is asking them to do
• Ask clarifying questions when they are unsure
• Implement what they are being asked to do in the code
• Trust the rest of the mob and be comfortable exploring approaches they would not normally explore
• Don’t prematurely challenge things; rather, implement what’s being asked and then review things
• Learn new things, like keyboard shortcuts and how their tooling works from others

Driver should only request an explanation (if needed) only after an idea has been expressed in code. Because drivers change frequently, it’s important they understand the code. If not, they won’t be effective when moving back as part of the rest of the mob.

Being the Driver is the best place to be when you’re not the expert, as by definition you only have to do what the rest of the mob is asking, while allowing the rest of the mob to be the experts. Being the Driver accelerates being able to “do it”, i.e. helps gaining expertise.

Navigators

Navigators are rest of the mob. They must remain in the same context all the time, sharing the cognitive load. Sharing and integrating ideas in real time using dialogue (talking and listening) and visual thinking* (with whiteboards, flip charts, sticky notes, …).

*Visual thinking creates a space of shared memory where ideas can remain longer, than a spoken word.

«Mob programming is continuous integration for ideas.»

Joshua Kerievsky

Team doesn’t stop thinking when it comes the first idea, we have to keep building the whole time, contributing the right thing… at the right time, in the right way.

These are the main functions of the Navigators:

• Help discover what the next logical step is to solving the problem
• Ask questions until you understand
• Contribute to increase the level of understanding in the mob
• Focus on the problem
• Listen to others
• Anticipate needed information
• Look for areas to improve the system

As a Navigators you are part of the problem-solving team. You have to help discovering what the next logical step is to solve the problem at hand; this is achieved by working collaboratively.

The Rotation

Team can stablish rotation protocol, for example every 25 minutes change the driver. There can also be a rotation if the driver wants to share an idea, because as a driver he cannot type it in directly.

The Skills

• Hearing and understanding others.
• Learn to Listen. Listening is not as easy as we think it is.
• Strive to understand. We might need to question each other.
• Be willing to try other’s people ideas.
• Open space for others to talk.

Practice these skills.

Sharing ideas

It is not a competition. There is no superprogrammer.

“Nobody is as smart as everybody.”

Kevin Kelly

When working in a team, no matter what the smartest person is, he becomes smarter.

We need to resist trying to prove how good you are.

Never insist in your own way of doing things . There is a thousand of right ways of doing anything, so we should never think ours is the one right way. Our thinking is just one option.

We are trying to build a shared understanding, rather than proving our idea is the best.

A Few Tips

When people is not undersanding what you are trying to say, assume that it is you, and not them. You probably should go to the whiteboard and try to find some alternatives way to share that idea.

«I just said that». We are not paying attention to the same thing at the same time, so, it doesn’t matter if someone express something shared before.

Choose and configure the editor to be the most confortable for most of the mob. Review shortcuts that are configured and try to agree on the ones most used by the mob.

Always display line number. Being able to see the line numbers significantly speeds up the on-screen code navigation.

When navigating, use absolute line numbers rather than relative line numbers, i.e. say “Move to line 45” instead of “Move down five lines”.

Setup a timer and make it visible (for example: https://agility.jahed.dev/).

Phsycological Safety

We need to include and honor every voice. If you say «that’s not a good idea», you are probably deshonoring them, sooner or later they will stop trying to help.

Bring those voices in. Listen as if the next being said is the most important thing you will ever hear.

Try all ideas.

Find out what works for your team

No one can tell you how to «best» work

Each team must learn for themselves how they can best work.

You can choose what works best for you.

You can change it as needed. Try things, reflect, tune, adjust.

Do frequent retrospectives: weekly, daily, at the end of each session… and turn up the good!

Protocols

One person at a time. Avoid side conversations.

Let people finish their ideas, not just their sentences. Often an idea requires more than one sentence.

Hold your thoughts. Make a note and share it later if still needed.

Contribute the right thing, at the right time, in the right way. We need to learn to control sharing.

Hand signals. To avoid interrupting person that is talking.

Mob Programming Session

An appropriate problem should have already been selected in preparation for the session.

A mobbing session consists of a beginning, a series of mob intervals, followed by a wrap-up at the end. The vast majority of your time mobbing is spent in mobbing intervals.

Setting the stage

This section should take around 30 minutes. It is assumed that everybody in the mob knows the roles and understand how to work together on the same thing.

Overview of the problem the mob will solve. The mob needs to be aligned on the general plan of attack on the problem. Get everyone to brainstorm different approaches to solving the problem at the whiteboard but limit the conversation to, at most, 15 minutes. Once there is an agreed approach, write down the high-level steps on the whiteboard leaving detailed implementation specifics for the actual mobbing intervals.

Finally, it is decided the order of the typists (very quickly, not more than 2 minutes).

Mobbing intervals

• The first person on the list takes the keyboard (they become the typist)
• Start the timer
• Mob works together on the problem
• When timer reaches zero, the typist stops and the next person on the list becomes the new typist
• Reset the timer and repeat the previous three steps until 20 minutes before the end of session

There will be some mob intervals where the mob will be dicussing an approach on the white board.

A good practice is to create a temporary feature branch and commit there changes after each mob interval. This branch is expected to be fast, so no rules, no commit message required. At the end of the mob session, all these commits can be done in the main branch.

Learning from the experience

Have a closing mob retrospective and discuss what went wrong, what went well, and how you can improve in the future.

How do we start

Start with simple things. Just practice on exercises. You need to get the skills.

Then, find something simple and contained to start with. For example a bug fix.

As grow your skills and capabilities, work on more difficult things.

---

References

• Remote Mob Programming by Woody Zuil, at Remove Forever Summit 2019
• MobProgramming
• Remote Mob Programming: Unleash your team’s potential with remote, collaborative work
• Seven Tenets of Mob Programming
• Mob Programming Introduction
• Collaboration, Pairing and Mobbing

MobProgramming