Mob programming is a collective programming discipline that fosters greater interaction with teammates, collective code ownership, and a sharp reduction in knowledge siloing. It can help a growing team to onboard new members and enables stable teams to produce quality work consistently without having to worry about scheduling. The discipline — sometimes referred to as ensembled programming — came out of the paired programming (or “extreme programming”) practice pioneered by Kent Beck. The idea that “one person would drive, and the other would navigate” has been popular ever since, though it’s never become entirely mainstream. Some teams use paired programming extensively; some use it occasionally, but find it hard to coordinate usage and difficult to keep people excited as the team grows. Mob programming, on the other hand, makes everyone part of the experience — which increases the sense of flow, helps to create a culture of learning, and builds a greater sense of collective code ownership.
In this post, you’ll hear about what our team has done to embrace mob programming. We have, at any given time, four to five engineers mobbing for 6–7 hours a day — and we’ve been doing this collectively for about a year now, complete with drop-ins from interested parties on other teams, stakeholders, and more. Our team is located around North America, and is fully remote. Some of us had prior experience with paired programming (but not mobbing) — some of us were brought into the fold on this team. We’ve found that mob programming has enabled us to enjoy a greater sense of belonging, appreciation, and collective team ownership; it’s also allowed each of us to take time off without having to worry about our expertise being needed to get things done.
Mob programming has been evangelized by Woody Zuill, notably in his presentation at GOTO 2019. The presentation is well worth a watch, as he breaks down how teams can stand to benefit from this seemingly contradictory notion — that more work can be done faster by having less people working at any given time. So how is it possible that having a virtual “room full of people” swapping off frequently can help teams increase their iterative performance? Because that’s what mob programming is about, at its core:
- one person “driving” — this person is supposed to act as a conduit to the computer. They can ask clarifying questions of their “navigator,” and they can run automated tests at any time.
- one person “navigating” — this person is the only one who can directly tell the “driver” what to do. The how can be freely interpreted by the “driver,” though the navigator ultimately has the last say. The navigator does not need to be an engineer (more on that in a bit)
- the “ensemble,” or “mob” — everybody else at any given moment. In our mob programming sessions, the “ensemble” can be filled with roles like other engineers, managers, our product owner or scrum lead; by other guests within our organization that are curious about mob programming; and by our stakeholders.
First, it’s important to ask the question — when’s the last time you observed that adding people to a team linearly increased that team’s output? It’s long been observed that there are diminishing returns when it comes to “throwing people at a problem,” especially in the world of software engineering. There’s a reason for this — beyond a certain size, ease of communication (particularly with regards to spreading ideas and being able to easily ask questions) breaks down. More people does not equal more output. Instead, more people frequently means more specialization — one person, or a group of people, get increasingly siloed in a specific problem or a specific codebase. Specialization increases at the expense of understanding. In essence, though a team in name, several smaller teams begin to develop — each focused on a particular domain. This (the specialization funnel) is an important prerequisite when considering how mob programming works.
Furthermore, the working world as we know it has been upended for nearly two years now by a global pandemic! With in-person collaboration severely curtailed — one of the previously common arguments against remote work, in general — new challenges have emerged as many teams and companies have moved to at least a hybrid working model. We’ve seen and heard again and again from teams struggling to come together as they combat a combination of:
- online meeting fatigue and the desire to keep abreast of team developments
- difficulty in receiving help when necessary
- the struggle to share exciting and empowering updates; to keep a group of people feeling a sense of “togetherness”
Mob programming can absolutely help teams feel engaged — even new teams that have only been formed during the pandemic! Plus, despite requiring screen sharing, online meeting fatigue is rarely experienced while actively mob programming. The reasons for this vary, but some commonly heard (and felt) ones from our own team:
- short mobbing sessions allow for ideation without exhaustion. As team size grows, this also means you have the chance for several “off-cycles.”
- frequent chances for feedback. While the navigator is supposed to be the only person who can direct the driver to type production-level code, it’s not necessary by any means for the navigator to be a developer themselves. As Woody says — the driver should meet the navigator at a shared, common level, and interpret their requests accordingly. As well, anybody else mobbing can bring concerns and questions to the forefront; the navigator can also seek the advice of anybody and everybody in the group
- no mandatory settings — while we do like to use our web cameras, we also actively encourage team members to mute, to take breaks, and to leave their camera off as befits their mood. Plus, there’s evidence that turning your camera off in video calls significantly reduces the greenhouse emissions necessary to make the call possible!
Changes In Process
Instead of focusing on specialization, and parallel streams of work, mob programming empowers the team to work through each challenge together. Knowledge is shared broadly, as are the pitfalls associated with failed approaches. Work collapses into a single stream. This is true regardless of the agile methodology embraced — scrum teams, kanban teams, scrumban teams, and more can collaborate equally well within the bounds of mob programming. We talk extensively here about the value proposition in shifting left (TL;DR performing testing earlier in the software development cycle), and mob programming can be a big part of that process. For instance — we frequently “throw things up on the page” when working on the frontend; the equivalent of writing a failing test on the backend might be simply getting something to show up on the frontend. We tailor our process to deliver the fastest result that can provide feedback.
Contrast this with the typical workflow of an individual contributor — somebody whose day-to-day involves grabbing items from a list (or being assigned work), working through roadblocks on their own (or, possibly, being forced to wait for help asynchronously from other teammates), and in general being forced to constantly search for or figure things out in isolation. There can be moments of extreme reward in this workflow; everybody loves to have that “aha!” moment — but the amount of effort that goes into getting to that point is frequently more draining than the moment of exultation.
As such, there are adjustments to each of the traditional scrum roles that are worth exploring:
- Our Product Owner is present in many of our mob programming sessions. She can provide feedback far earlier in the process — and we can codify and represent that feedback, not only in the way of updating acceptance criteria in a story, but within actual tests that increase our confidence in our product and empower us to make refactorings whenever necessary without fear of regressions. This, returning to the concept of “flow” introduced at the beginning, allows for less in the way of ceremony and more in the way of delivering results consistently in line with expectations.
- Our Scrum Lead has the chance to give us faster feedback, as well, offering guidance on when to buckle down and tackle tech debt and when to switch gears into “delivery” mode as we approach the end of each sprint. They also help us, day to day, in terms of staying on track, in addition to being able to offer feedback and advice as a Subject Matter Expert (SME) for our applications
- Our Engineering Manager — in addition to getting the chance to be in the trenches as an engineer (both “driving” and “navigating”), gets the chance to shift from directing what the solution should be to fostering a healthy, safe, and encouraging environment for the rest of the team, out of which the actual solution can emerge
- Our engineers — instead of focusing on who “owns” any given piece of work, we are all focused on ownership in all of its various forms. This is a broad definition — as part of producing code, we’re also producing documentation, architectural decisions, automated tests, and more. We share in the collective success of our team; we own, collectively, our mistakes. We also all get the chance to give feedback continuously, which makes our code reviews much less intense; by the time an item gets to code review, it’s typically just a matter of waiting for our automated pipeline to complete prior to approving (instead of a days-long game of feedback ping-pong)
More on How Mob Programming Affects Ownership
In a more traditional team, the idea of collective code ownership comes down to how a team manages tasks. An experienced team with great supporting structures in place can indeed exhibit highly motivated engineers capable of jumping in and taking ownership over any issue, or helping to bring something across the finish line. This is the ideal state with a more traditional team structure — and it’s frequently unattainable, or hampered by subject matter expert (SME) availability. If the SME who worked on a particular code block isn’t present, making progress on the issue could mean quite a bit of additional time expenditure; in a complex enough application, the time that it would take to bring another engineer up to speed frequently outstrips the amount of time that engineer would have to complete their hotfix. In the event of staff turnover, this problem is compounded — now you have an incredibly hard to maintain application without the benefit of the knowledge that went into making the decisions that led to the program’s current code iteration. All too often, an on-call engineer receives a 2AM page for a piece of code that isn’t theirs and is left scrambling to work through the issue.
We’ve experienced the benefits of shared code ownership firsthand; our team in its present shape has been mob programming since March 2021. In that time period, we’ve added several teammates as individual contributors, and said goodbye to others. At no point has turnover affected our ability to produce, added stress to management or our stakeholders, or put any one single contributor into a bind. Our collective ownership has led to a team that’s more resilient and more welcoming — exactly the qualities we were hoping to cultivate.
Contrast this with the mob programming approach: instead of developing deep, siloed knowledge, the team as a whole expands its understanding and knowledge of applications. Ownership is an inherent part of the process for every member, regardless of role, tenure, or experience. We, as a team, spread roots into our applications: progressively expanding every member’s knowledge as we go. This doesn’t eliminate product or technical expertise, but it does help to minimize the impact of rotating schedules and meetings that conflict with mob programming time.
To go back to the change experienced by individual contributors, there’s a massive difference for every party involved. Code review, in particular, becomes an iterative part of the process (instead of something backloaded onto the end of the process). Because stakeholder feedback can be incorporated on the fly, there’s also much less context switching — we stay with a story more consistently, and get it to the point of being ready to be deployed in less time as a result.
Closing Thoughts
We recognize that process changes can be intimidating, but encourage you to explore mob programming if you’re looking for a way to improve team cohesion and deepen team knowledge at the same time.
Here are some things you might find surprising (as we did!):
- Standups are incorporated into our daily mobbing sessions in a very organic way. We leave notes for ourselves, when necessary, to remind us collectively if we had outstanding questions from the day/week prior. We also make a point to review the work we have left in our sprint at any given time, to ensure nobody has concerns with the amount of work we have yet to accomplish.
- We are open to others joining at any time during our mobbing sessions.
- We are the opposite of “death by committee” and are focused on effectively communicating to accomplish our goals.
- It’s totally fine to not know how to implement something, or how to solve a problem. Your teammates are there to help and guide you. Instead of struggling through a problem alone for an hour or two, everyone starts from the same square and those with pertinent past experiences can help to guide the conversation and coding patterns
- New members to the team, particularly engineers, find their onboarding is jump started. By being on a call with a handful of individuals familiar with the work the new hire will be conducting, any issues, oddities, and otherwise day-long hang-ups are quickly resolved. By seeing the other members program in a mob setting, new members are able to become familiar with both the personalities and programming styles of their team — a benefit even more valuable in our increasingly remote world.
- Team members have almost never met in person!
These surprises have all been good ones, for us, and we’ve continued to espouse mob programming for teams interested in shaking things up and experiencing a more collaborative workflow. Give mob programming a try, and let us know what you think!
James Simone is a Senior Software Engineer at Salesforce, and has been featured on the Salesforce Developer Podcast, the Developer Blog, and also writes extensively about Salesforce development on his own blog, the Joys Of Apex. He’s passionate about Test Driven Development and, as a prior practitioner of Extreme Programming, has been extremely happy having made the move to mob programming.
