What Is Mob Programming (Software Teaming)?

Reviewed by: Paul Moore (CSAT, CSP-D, CSP-SM, CSP-PO, A-CSD, CSD, CSM, CSPO)

Mob programming involves everyone—including non-coders like people in QA and Product—working together on the same piece of code to make it as good as possible in one pass. Mob programming is also called software teaming or ensemble programming.

For many people, coding is solitary work. They may prefer to be alone in their space to think about the software they're writing and the challenges they're facing to come up with their own solutions.

Although this allows them the freedom to concentrate and create without interruptions, the code is only as good as the individual alone can make it, and improving it will likely take rounds of reviewing, testing, and rewriting by other team members. This takes additional time not just for the other team members to look at it but also to hand it around and wait for each team member to find the time to work on it. 

What if, instead of all this handing the code around, you could get feedback from the rest of your team, in real time, as you write? Then you would be able to test and rework the code as you went, and when you were finished the code would already be as good as your team could possibly make it. Enter, software teaming, a.k.a. mob programming.

What is mob programming?

Mob programming is a collaborative programming technique in which an entire team works on a coding task together. While traditionally this often involved using one computer in the same room, today's commonly distributed and remote teams are fully capable of software teaming from different locations by sharing one codebase via a remote repository and working locally on their own computers when it is their turn to drive. One person works on the keyboard while the other people collaborate and make recommendations. Ideally, the team isn't just writing code but checking, testing, and reviewing as they go. 

There's a common misconception that in mob programming, one person is working while everyone else is watching. In truth, everyone should always be participating to some degree, and everyone rotates through all the roles on a regular basis. 

Software teaming, mob programming, or ensemble programming?

All of these terms refer to the same collaborative team-working session. Mob programming tends to be more widely used but is the older term. Some technologists today prefer the more collaborative implications of "software teaming," while people outside the U.S. tend to use the phrase "ensemble programming." 

What is the mob programming process?

Reading a basic description of mob programming can give you many misconceptions about the practice. One we've already mentioned is that the practice involves just one person working while everyone else is just sitting around watching. Another is that the process is chaotic. This can sometimes be the case, but the mob programming process works to control the chaos and harness everyone's effort, skills, and focus toward accomplishing the task at hand. 

When to utilize mob programming sessions on an agile team

Mob programming can fit into any agile framework. A team can decide to utilize mob programming whenever it's appropriate and productive. Some situations where teams utilize it include:

• Tasks that benefit from the combined expertise of the entire team
• Faster knowledge sharing through actively solving problems instead of reading documentation
• Development of hard or soft skills is required by individual members or the entire team
• The team needs to shoulder work together because of deadlines, stress, exhaustion, or absences

Many teams use mob programming strategically for specific tasks, but some make it their standard operating procedure. 

Configuring a mob programming session

A mob programming session is set up to tackle a specific task. In scrum lingo, this might be anything from one item in the product backlog to a larger section of value from the backlog, depending on how the team operates. However, it's important to define the goal for the session. 

Remote mobbing

Many software developers work from home. According to the New York Times, 64% of software developers were working from home in 2021. That trend persisted in the years following, with Dice reporting that over 80% of developers either worked remotely or hybrid in 2022, and Turing reporting that 86% of developers were working from home in 2024.

So is software teaming possible in this brave new world of remote work? You bet!

There are two main ways to accomplish remote mobbing:

• Everyone works locally on a shared code repository
• Remotely logging into a single machine to remote control the driver's computer

Once you have remote collaboration mechanisms established, you can follow the same general steps as the in-person software teaming described below.

From the same location

Configure the space and the team for the session. The space should ideally be a single physical location with a single computer (though possibly multiple displays) for coding. Some teams allow secondary computers for research and support, but this should be restricted in two ways. 

First, the code should only be in one place, with everyone working through a single keyboard. Second, other computers should only be allowed if the team can retain focus on the central task without team members getting distracted and not participating.

The team should have everyone available to work on the task: a mob programming team often has three or more members. When a scrum team is software teaming, the product owner and the entire team should participate so that they have a shared understanding of the work. Over time, this collaborative process helps the product owner and other stakeholders understand the effort and work that goes into such a session and why the team forecasts work for a sprint the way they do.

Conducting a mob programming session

During a mob programming session, the entire team works together on the defined task or backlog item. Over the course of the session, each person in the team will rotate through the different roles in the mob programming team, which typically include:

• Driver: The driver is the team member working at the keyboard. They will follow the directions of the navigator. The level of autonomy granted to the driver is up to the team, but in general, the driver is merely the one who creates the code, not the one who decides what to create. 
• Navigator: The navigator is the team member who decides what to create. They listen to the mob's ideas, make judgments about what is best to add to the code, and then translate those judgments into a series of instructions for the driver.
• Mob: Every other team member is part of the mob. The mob's job is to generate ideas about what to produce and interrogate the code being produced to ensure that it will perform as required; this may include research into language and framework capabilities, documenting decisions made in the team's knowledge repository, or pointing out code smells. The mob is part brainstorming session, part quality assurance, and part supervisor. 

Software teaming is not meant to be prescriptive. You can read more about the role possibilities here.

Rotation occurs regularly according to the team's rules. Typically, rotations occur every 10-15 minutes. 

In addition, some teams like to use a Champion to manage the mob programming session. This person has the responsibility to make sure the team is following the session rules: rotating on schedule, staying on task, performing their roles as required, and anything else necessary to maintain productivity during the session. The designated Champion acts as Champion throughout the entire session, while also rotating through the other roles when it is their turn. Think of a mob programming session like a volleyball rotation. Every team member will rotate through all positions on the floor and take a turn as server, but the captain always remains the captain. 

Benefits vs. downsides of mob programming

Mob programming is an approach that fits nicely into agile frameworks because it draws on many agile principles like collaboration and shortened feedback loops, as well as scrum values. For example, scrum values like focus, openness, and respect are a strong foundation for successful mob programming sessions. In addition, mob programming sessions are an exercise in transparency and inspection. Mob programming reinforces the lack of hierarchy among developers by having individuals rotate through the mob roles without priority or preference. 

Many agile teams find mob programming a useful and productive approach, but it may not be ideal for every team. 

Benefits of mob programming

Mob programming can help teams accomplish difficult programming tasks because of benefits like:

• Knowledge sharing: When teams work together as a mob, they will automatically share their knowledge, which spans domain knowledge, language and framework idioms, and tool capabilities. This knowledge-sharing supports bidirectional learning that can significantly improve the skills of every team member. 
• Team building: Instead of arbitrary "team-building exercises," mob programming builds teams around a meaningful, productive activity that is central to their mission. This can help teams develop mutual respect and improve their functionality both inside and outside mob programming activities. 
• Efficiency: Mob programming can help teams develop product increments faster by integrating many parts of the development process (writing, reviewing, revising, testing, etc.) into a single session. This not only supports early value delivery but also eliminates cumbersome communication delays. 
• Resilience: The unavailability of an individual team member due to illness or attrition never stops the progress of a programming mob. In addition, sharing the development load can allow some teams to remain productive for longer periods of time. Although everyone in the mob is encouraged to participate constantly, developers can allow themselves times of low activity to rest and recover so that the mob can work for more hours than any individual could. 
• Quality: Because the entire team is constantly inspecting the code produced, there is a lower risk that key details (such as specific user requirements) will be missed. Also because the team is working together to produce code, there is a lower risk that an individual user will create tangential functions that do not add value to the final product. Mob programming can be a great way to ensure quality when there is low tolerance for errors. 

These benefits help teams that can successfully deploy mob programming to produce higher quality code faster. 

Potential drawbacks of mob programming

Although mob programming can be highly effective, not all teams can make it work for them. Some reasons why teams fail at mob programming include:

• Skill imbalance: Although mob programming works well to help balance the skills of all team members, it doesn't work if the imbalance is so great that only one or two team members are capable of performing the task. In this case, the rest of the mob may become a drag on the productive members, who could do more if allowed to work on their own or as a programming pair. 
• Lack of cohesiveness: As with knowledge sharing, there are limits to how much team building mob programming can accomplish. At a minimum, a driver must always have enough respect to do what the navigator says, not what the driver thinks is right. All mob members must feel comfortable and confident enough to speak up. Otherwise, mob programming can't function effectively. An effective Champion can help detect and head off some of these challenges.
• No investment in technique: For the process to work, people must also respect it. People who lack confidence in the approach may either not put in enough effort or actively subvert the team's progress. 

Because there are both pros and cons to mob programming, you should try it out with your team to see how it goes. Talk about the process in the following sprint retrospective to determine if there are action items to improve the experience.

What are alternatives to mob programming?

Although not every team can effectively utilize mob programming, there are some alternatives that can offer some of its benefits while avoiding its drawbacks. 

Pair programming

Pair programming is an inspiration for mob programming and a core practice in the agile framework Extreme Programming (XP). In pair programming, two people sit next to each other and produce code by turns, passing the keyboard and mouse back and forth as each takes control. Pair programming works well when you have team members with equivalent experience and skills—pair programming is not intended as a mentoring relationship and doesn't provide extensive knowledge sharing. It also doesn't provide the same resilience as mob programming. However, it does offer efficiency and quality benefits similar to mob programming, and perhaps even more because the developers are both experienced. 

Collective code ownership

Collective code ownership is a core element of many agile frameworks. The code produced by the team is seen as owned by all, giving every team member the right to alter the code at any time and in any way. This allows everyone to bring their insight to the code and allows for simultaneous development and testing, but it doesn't allow for collective oversight and decision-making as team members can alter the code without the team knowing or approving it. Nor does it eliminate communication difficulties. 

With collective code ownership, anyone can make changes to code but not everyone will be aware of the changes as they are made. This can add delayed feedback when a change is made that violates a standard, introduces a bug, or is in opposition to a simultaneous change made by someone else on the team.

Mob programming: A useful tool for agile teams

Mob programming isn't right for every team or task, but there are times when it can be extremely useful. Although it sounds chaotic—and it can be—the rules of the approach can make it productive. By pooling your team's expertise, you can ensure higher-quality code while also growing your team's expertise. Teams that use it well can actually be more productive mobbing than working individually. 

Interested in the agile principles at work in mob programming? Learn more about enhancing collaboration, delivering incrementally, and improving product quality with agile methods in the Certified Scrum Developer course. You can upgrade your skills to become a scrum developer who leverages adaptable ways of working to deliver faster and increase customer value.

Explore Certified Scrum Developer courses