Mob Programming - My Definitive Guide

This article is from the pre-AI coding era, originally published pre-2025 on my Medium account and ported here.

Those who do know about it will probably tell you that mob programming is everyone in a group working on a single computer. While this is true, the real purpose of mob programming is for someone to perform work, it first has to come from someone’s mouth.

In this article, I will share how a standard mob programming session is done, both remotely and in the office.

Afterward, I will share some classic pitfalls that teams fall into when first trying out mob programming. These pitfalls can vary widely (this is where I say “#3 will SHOCK you!”), and can be difficult to know beforehand.

Finally, I will share some of the success indicators that you’ll notice early on as you embark on a very different way of working.

Where Did Mob Programming Come From?#

While the work of mob programming has appeared in many situations (even back when NASA was still scrambling for solutions during the race to the moon), mob programming was the evolutionary next step for people who had practiced XP (Extreme Programming), a concept brought to the world by Kent Beck.

Why Did Mob Programming Become A Thing?#

After many programmers realized that pair programming was a good way to raise the long-term quality of your work by sharing knowledge, bouncing ideas, and realizing a bad direction sooner rather than later, being more than two people raised the quality even further.

Now there are teams in the world who do mob programming all the time and get more work done than the average team, because:

• Barely any time is spent fixing bugs
• The right knowledge is present in the mob
• The knowledge is shared perpetually as team members enter/leave the team as a built-in onboarding/offboarding mechanism.
• No overhead roles are needed to organize the team for the team (however weird that sounds, that’s the reality most times)

While every team is different, and many teams have their unique setups for how and when they best do mob programming, it is becoming a more and more well-known strategy for building long-lasting and self-sustaining teams that drive themselves not only for successful deliveries but also for successful products.

How To Do Mob Programming?#

The Prerequisites#

For a standard mob programming session, you’ll need these things:

• A timer (just google “mob timer”, or use the one I created once for fun https://mobcampfire.netlify.com/)
• A single computer with a monitor that everyone can observe, or screen-sharing capabilities if you are working remotely

The Goal#

The goal of the mob is to achieve positive outcomes by collaborating as a group to solve a series of problems or challenges.

A mob session is not a competition and it is not a code-fest: You’re here to solve problems. Everything else, from whiteboarding to typing on the keyboard, is just a side-effect of your journey to success.

This can be challenging for some individuals who just want to code, but if we are to do our jobs well, it’s not about how much you get to type on a keyboard. Rest assured, I will cover ways to stimulate these individuals as well.

The Roles#

Driver: The person who sits at the computer. This person is only allowed to follow instructions and ask questions for clarification. “Do you mean here?” or “So should I add a new condition above the old one?”

Navigator: The person who orchestrates the direction of what to do next, and ultimately the instructor to the driver. I usually like to say that if things become too chaotic or too quiet, we fall back on the navigator to pick up the ball.

Others: Everyone else’s job is to support the navigator by contributing to discussion, or asking questions. The mindset you should have is to help the navigator to achieve success without becoming the navigator yourself. You also should refrain from telling the driver what to do without going through the navigator as that could lead you to quite a chaotic session.

Note #1: It is generally a good practice that all participants really participate, not just lurk in the mob. If you’re a manager, don’t sit in a corner with your laptop out unless everyone is extremely comfortable with you sitting there, otherwise, it will likely make people uncomfortable to talk as openly as they would otherwise.

Note #2: Mob Programming should always involve the “Law of Two Feet”. That means, if anyone wants to get up and leave, they should be allowed to do so.

The Rotation#

When you do mob programming, you rotate the roles. This is done by setting the timer to anything between 5–15 minutes. The more participants, the lower the timer. For any group just starting out, I will always recommend no more than 5–6 minutes. When the timer runs out, you rotate the driver and the navigator.

A house rule you can employ when you’re getting slightly more comfortable is for the group to finish what they were doing before rotating. Just be mindful not to get stuck for more than a minute or so.

The rotation should be seamless and take no more than 10–20 seconds. The thought process is not supposed to stop when you rotate, and ideally you’ll still be talking as you rotate.

In office: Make sure you have a room where people can physically rotate. It is much easier to keep the driver and navigator seat static while everyone just moves around.

Remote: Since the driver will have to commit their work before passing to the next screen-sharing driver, I strongly recommend every participant gets a tool like mob.sh which is a lightning-fast way to commit and handover the changes.

The Challenge#

When first trying out mob programming, I recommend doing the following:

Adopt TDD (Test-Driven Development): To make sure everyone in the group can discuss things on the same wavelength, divide your problems into small bits of failing tests. In TDD, the idea is to

1. Write a test of how you’d expect an implementation to work (input X equals output Y)
2. Implement the logic, causing the test(s) to pass
3. Refactor if the group deems it necessary
4. Go back to step 1.

This is also known as Red-Green-Refactor.

Start with a code challenge outside your regular project(s): The last thing you want to be stuck on when first trying out mob programming is:

• Getting the project to run on a computer that has never compiled it before
• Trying to figure out how to write tests in an existing repo with little or no tests
• Having one person who knows 10 times more than everyone else about the pre-existing code.
• Picking a challenge that is too difficult. This one is easy to underestimate!

These are not unworkable conditions, but they cause hazy conditions to determine the benefits of mob programming for your team.

I generally recommend using cyber-dojo.org as a place for doing code challenges. It has a plain and simple IDE that doesn’t give benefits to anyone used to a certain editor, and it has code challenges ready to be tested.

While it may be tempting to pick a difficult challenge, I’d recommend starting out with Closest To Zero or Fizz Buzz. Before starting, it’s a good idea to make sure that nobody in the group has done this code challenge before, to further level the playing field and give everyone a chance to contribute equally.

Do Mini-Retros: After working for 30 minutes or so, you should take a small break, and have a mini-retro before or after that. A mini-retro is extremely simple; just go around the table and let each person share either good or bad things they experienced during the session so far. Nobody needs to say anything profound; if you agree with the last person who said something, just say “what they said” and move on.

A variant of this is to do “Turn up the good” retro, where you only bring up good things. This inspires the group to focus on the good things that you were doing in order to try to “turn up the good”.

Keep the flow going!#

If you’re getting stuck as a team due to things like missing knowledge, take the steps needed to get your team back on track. Need your product manager? Call them in!

With that said, if you’re waiting for example for a build to pass, use those opportunities to take breaks, or do some watercooler talk to simply bond a bit as a team. These moments have a lasting long-term value that is not to be undervalued.

Transcript from a Mob Session#

Here’s a typical transcript of a how a mob session could go with a team trying to solve a Closest To Zero code challenge.

Closest To Zero Given a list of integers find the closest to zero. If there is a tie, choose the positive value.

Dave (The Driver): Alright Nami, what do I do? Nami (Navigator): Could we look at the challenge description? I didn’t completely catch what we needed to solve. Dave (The Driver): Opens the README.MD Nami (Navigator): OK, so I guess we need to pass in different arrays of numbers, and we’re just supposed to write the simplest first test that will fail? James: That makes sense. Red is good!

Group snickering

Nami (Navigator): OK, Dave could you open the tests file and pass in an array with a single element, with the number zero in it? Dave (Driver): Alright, done! Nami (Navigator): OK, now let’s run the test. Dave (Driver): Fail!

Nami (Navigator): Great success! for the code, I want you to return zero, then run tests. That’s it. smug face Dave (Driver): Done, and it works! William: Ship it!

Group laugh

The group would then move on to create another test, that would require returning something other than a hard-coded zero in the logic. Finally, they’d have enough passing tests to solve the challenge completely.

Writing hacky solutions that make the current test suite pass should be considered a sport! Don’t give in to the idea of spending 60 minutes whiteboarding a masterful solution that solves all tests in one go. You can always refactor it later during the session.

Sometimes writing these small bits of tests may seem unnecessary, but remember that mob programming isn’t about solving the most complex logic when you’re just getting started, it’s about bringing the group forward together with a working group dynamic, a muscle that you’re very unlikely to have been flexing to this extent before.

I cannot stress enough that it’s really important to have mini-retros often to be able to see early what could be improved.

BONUS: Interview Candidates With Mob Programming!#

One of the most effective ways of interviewing candidates I’ve ever experienced has been to do mob programming with the candidate.

All you need to do is to follow the above rules (be mindful not to single out the candidate in any given situation) with the candidate and 1–3 participants.

A good rule of thumb for the session duration is to add 30 minutes for every participant. So if you’re 4 people, be prepared to spend 2 hours together.

While I urge you not to skip the next part of this article (that’s where things get juicy), I’ve written an article on why mob programming in interviews is so powerful, feel free to give it a read.

The Pitfalls of Mob Programming#

So now we’ve covered the basics of mob programming and how mob programming can work when starting out as a team.

Now we’re gonna get into the bits where mob programming tends to cause negative commotion inside a company, and I’d like to allow you to navigate these parts more cautiously.

Please note that while I’ve generally found these things to be true in my past experiences, your situation may differ. Apply common sense!

Technologies - Gotta Stack ‘Em All! (go Fullstack)#

When doing mob programming, it is extremely beneficial if the team has an open mind to learning about all technologies*.*

While you can have mob sessions only around the frontend or backend, ultimately this will hinder the capacity of the mob and will limit the availability of knowledge.

Optimally, backenders should rely on the frontenders and vice versa. Not to forget about other roles as well.

Contribution Takes Many Forms - Including Learning#

When mob programming, it will be common for team members to express that they don’t feel that they’re contributing enough value to justify their participation, either because they’re unfamiliar with the solutions, or because they already know how they would move forward if they were working alone.

Many of us are in company settings accustomed to that contributing value is “shipping as much as possible”, which is flawed thinking.

Contributing to a company’s success can be so many things, like:

• Sharing knowledge, leveling up your teammates in areas
• Gaining new knowledge, improving your skillsets.
• Bonding with the team, improving future communication
• Solving problems that would take a long time to solve alone

When this happens, other than highlighting the above, I have two things prepared to say depending on the person.

To The Senior Developer: If you want to take on the role of a senior, you need to take responsibility for more than just code, for example, learning how to teach and when to give responsibility to others. When I am managing people, this is how I define seniority to them. It’s not enough to just keep learning how to code.

To the Junior Developer: Your biggest contribution to the team is to learn. Our industry has so many things to learn and work with, and sitting in a mob as a junior developer is a large testament to that. As a junior, you need to be ready to mob for at least 3–6 months before you feel comfortable delving in and out of various concepts and technologies. Once you’re at that point, you’ll be more experienced than almost every person around you who didn’t do mob programming to learn.

With this said, there’s a known concept within the mob programming scene called Dedicated Learning Time. This is time spent by individuals potentially working alone to learn more about something that came up in the previous mob session(s) or to try to fix a problem that the mob got stuck with last time. This will usually happen naturally (say the mob starts at 09:00, and people spend time before 09:00 to have Dedicated Learning Time). If anyone feels guilty about spending time like this, let them know that everyone needs some Dedicated Learning Time.

If you find that teammates are simply struggling to retain focus; if you haven’t strayed from a strict mob timer ensuring that they get their time as driver and navigator, another option is to give them an advanced challenge in the world of mob programming to try to level up their interpersonal skills, trying to do things new to them like “trying someone else’s idea first”, “talking when spoken to” or “ask as many questions as possible.”

It is up to you where you think is reasonable to tell your team.

The First Rule of Fight Club…#

If you’re in a company where mob programming isn’t a common practice, you may want to avoid spreading the term lightly.

For many people outside the immediate development teams (stakeholders, managers), the programming team is like a golden goose that gives gold eggs — They have no idea how the golden eggs come to be, but they want to keep them coming at the same pace or faster.

While there are plenty of arguments as to why mob programming would create more golden eggs (especially ones that aren’t rotten on the inside), this is likely not a battle you should be equipping yourself for if you’re just trying it out.

My advice is to keep the concept of mob programming within the team and book it under the guise of a “team-building meeting” for half a day.

Some may interpret this as dishonest, but I’ve seen too many instances where managers shoot down ideas for how teams should work based on unfounded fear of loss of productivity. Sometimes teams just need an opportunity to try new things without alerting everyone else.

If you’d like to inspire mob programming to a company as a whole, I’d recommend inviting a public speaker like the godfather of mob programming Woody Zuill. Woody is an expert on talking about mob programming to all audiences, including managers who need to look at the benefits from more economical aspects. You can see one of his best talks here.

Quality is Not Always Possible#

Some companies are unfortunately ill-positioned to do mob programming because their working environment does not give the capacity for quality.

For example, this can be true for agencies that have customers looking for project-based estimations, short-term work, or low-level commitments.

For example, if you have a customer paying you the equivalent of one full-time developer, the only way to make that work in a mob is to have 4 developers spending 25% of their time together with that client, basically 1 week per every month. If the client expects reported activity every week, mob programming is going to be a difficult thing to explain to them. Not every company is in a position to turn down a client who does not want to invest in a bigger team and long-lasting long-term quality.

With that said, you should still try to do mob programming as a team-building activity, but you may need to tweak the concept to fit your company’s constraints.

The Team Within The Team#

One thing I’ve found to be regularly occurring is that mob programming has a tendency to create more clear contours around the team within the team.

What this means is that once you’ve gotten started mob programming, some people will say that they’re not finding the time to participate, or perhaps even openly say they don’t have time.

This is fine, but do pay attention to the developments here. For example, if a senior developer never wants to join the mob, perhaps you need to adjust the team composition or split up your team meetings into smaller working group meetings to keep a good level of relevant discussions.

You’ll also find that some teams will start to argue a lot over what seems to be the tiniest details. These are things that developers have not been used to arguing about before. A good house rule to employ here is “Let’s try it your way”.

Some arguments won’t settle for weeks. Don’t take these debates as a bad thing, even though you might need to cut them short sometimes for the sake of the group. Think of it as the team making up for past lack of communication. Heated debate is great, as long as we continue to respect each other.

People Dynamics Don’t Always Work#

With the above in mind, sometimes, a certain group dynamic just doesn’t work.

You should not try to make mob programming work no matter what if it’s clear that it’s making people too uncomfortable.

With that said, if your goal is to drive quality through collaboration and you can see that some individuals do work well together, you may want to look at adjusting the team composition, either formally or informally.

The Success Factors of Mob Programming#

There are many benefits to mob programming, but if you’re experiencing any of the below, you should know that you’re heading down the right path.

Meetings become Redundant#

If you suddenly start to question why you have a stand-up ceremony, that’s a sign that you’re collaborating enough to not have to have them.

This is one of the earliest signs of mob programming helping you out.

Worst case, if managers want to know what the team is up to, you can keep the standup but keep it short and sweet, alternatively send off one or two people to join the standup, letting everyone else focus on the standup.

Onboarding new People becomes Easy as Pie#

It’s been 2 months since you hired a new junior developer, and nobody really thought about it until now, but this person is already getting pretty good at your code base!

With an easy way to ask questions and participate in more than menial development tasks, mob programming is any junior developer’s dream to level up extremely quickly.

Keep Calm and Keep Mobbing#

Mob programming takes away a lot of the needs for additional meetings, managers having to puzzle together certain resources, and people having different opinions, taking it out in various forums.

When you’ve got teams that are meshed well enough to do mob programming every day, simply put, the drama goes down.

If you are a manager and want a company that runs like a well-oiled machine, mob programming is the best ingredient I’ve found to make that work.

It’s like what they say about electric cars vs. fossil fuel cars — If an electric car consists of a few parts (mob programming) and fossil fuel cars consist of literally a thousand parts (scrum ceremonies and meetings); it’s no wonder that so many car manufacturers can produce and sell electric cars successfully.

BONUS #2: Helpful resources to learn more about Mob Programming#

There are many ways to learn more about mob programming, I will list some of my favorites here.

Mob Mentality Podcast: This is a podcast entirely dedicated to mob programming. They have so many episodes, so you can be sure to find something that relates to your interests within mob programming. Spotify, Apple Podcast, YouTube

Woody Zuill Talks: Woody was the person who coined the term “mob programming” (a term he’s actively rebranding to “software teaming” for inclusivity as “mob” can have negative connotations in some languages). I strongly advise looking at his talks. YouTube

Massive Trello Board of Mob Programming Goodies: Put together by the mob programming community, this board is guaranteed to pique your interest in one way or another. Trello Link

What Is Mob Programming, Video Format: If you want to give your teammates a quick rundown, a video may be helpful. YouTube

Companies That Do Mob Programming: Interesting Trello Board to see who does mob programming out in the world. Trello Link

Bottom Line#

I’ve been wanting to write this article for a very long time, and now that I’ve been mob programming for almost 4 years, I am so happy to be part of the the mob programming community, a place that is so much more wonderful than others parts of our industry.

If you find a company that does mob programming and you want to have a good time with your teammates solving complex problems (not be stuck fixing menial bugs due to typical Scrum environments), you can be sure that you’ll enjoy it there.

Thanks for reading.