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\u200a\u2014\u200asometimes referred to as ensembled programming\u200a\u2014\u200acame out of the paired programming (or \u201cextreme programming\u201d) practice pioneered by Kent Beck. The idea that \u201cone person would drive, and the other would navigate\u201d has been popular ever since, though it\u2019s 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\u200a\u2014\u200awhich increases the sense of flow, helps to create a culture of learning, and builds a greater sense of collective code ownership.<\/p>\n
In this post, you\u2019ll hear about what our team has done to embrace mob programming. We have, at any given time, four to five engineers mobbing for 6\u20137 hours a day\u200a\u2014\u200aand we\u2019ve 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)\u200a\u2014\u200asome of us were brought into the fold on this team. We\u2019ve found that mob programming has enabled us to enjoy a greater sense of belonging, appreciation, and collective team ownership; it\u2019s also allowed each of us to take time off without having to worry about our expertise being needed to get things\u00a0done.<\/p>\n
Mob programming has been evangelized by Woody Zuill, notably in his presentation at GOTO 2019<\/a>. The presentation is well worth a watch, as he breaks down how teams can stand to benefit from this seemingly contradictory notion\u200a\u2014\u200athat more work can be done faster by having less people working at any given time. So how is it possible that having a virtual \u201croom full of people\u201d swapping off frequently can help teams increase their iterative performance? Because that\u2019s what mob programming is about, at its\u00a0core:<\/p>\n one person \u201cdriving\u201d\u200a\u2014\u200athis person is supposed to act as a conduit to the computer. They can ask clarifying questions of their \u201cnavigator,\u201d and they can run automated tests at any\u00a0time.one person \u201cnavigating\u201d\u200a\u2014\u200athis person is the only one who can directly tell the \u201cdriver\u201d what<\/em> to do. The how<\/em> can be freely interpreted by the \u201cdriver,\u201d though the navigator ultimately has the last say. The navigator does not<\/em> need to be an engineer (more on that in a\u00a0bit)the \u201censemble,\u201d or \u201cmob\u201d\u200a\u2014\u200aeverybody else at any given moment. In our mob programming sessions, the \u201censemble\u201d 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.<\/p>\n First, it\u2019s important to ask the question\u200a\u2014\u200awhen\u2019s the last time you observed that adding people to a team linearly increased that team\u2019s output? It\u2019s long been observed that there are diminishing returns when it comes to \u201cthrowing people at a problem,\u201d especially in the world of software engineering. There\u2019s a reason for this\u200a\u2014\u200abeyond 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\u200a\u2014\u200aone 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\u200a\u2014\u200aeach focused on a particular domain. This (the specialization funnel) is an important prerequisite when considering how mob programming works.<\/p>\n 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\u200a\u2014\u200aone of the previously common arguments against remote work, in general\u200a\u2014\u200anew challenges have emerged as many teams and companies have moved to at least a hybrid working model. We\u2019ve seen and heard again and again from teams struggling to come together as they combat a combination of:<\/p>\n online meeting fatigue and the desire to keep abreast of team developmentsdifficulty in receiving help when necessarythe struggle to share exciting and empowering updates; to keep a group of people feeling a sense of \u201ctogetherness\u201d<\/p>\n Mob programming can absolutely help teams feel engaged\u200a\u2014\u200aeven 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\u00a0team:<\/p>\n short mobbing sessions allow for ideation without exhaustion. As team size grows, this also means you have the chance for several \u201coff-cycles.\u201dfrequent chances for feedback. While the navigator is supposed to be the only person who can direct the driver to type production-level code, it\u2019s not necessary by any means for the navigator to be a developer themselves. As Woody says\u200a\u2014\u200athe 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\u00a0groupno mandatory settings\u200a\u2014\u200awhile 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\u2019s evidence that turning your camera off in video calls significantly reduces the greenhouse emissions necessary to make the call possible<\/a>!<\/p>\n Photo originally from <\/em>https:\/\/devopedia.org\/shift-left<\/em><\/a><\/p>\n 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\u200a\u2014\u200ascrum 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<\/a> (TL;DR performing testing earlier in the software development cycle), and mob programming can be a big part of that process. For instance\u200a\u2014\u200awe frequently \u201cthrow things up on the page\u201d 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.<\/p>\n Contrast this with the typical workflow of an individual contributor\u200a\u2014\u200asomebody 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 \u201caha!\u201d moment\u200a\u2014\u200abut the amount of effort that goes into getting to that point is frequently more draining than the moment of exultation.<\/p>\n As such, there are adjustments to each of the traditional scrum roles that are worth exploring:<\/p>\n Our Product Owner is present in many of our mob programming sessions. She can provide feedback far earlier in the process\u200a\u2014\u200aand 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 \u201cflow\u201d 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 \u201cdelivery\u201d 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 applicationsOur Engineering Manager\u200a\u2014\u200ain addition to getting the chance to be in the trenches as an engineer (both \u201cdriving\u201d and \u201cnavigating\u201d), 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\u00a0emergeOur engineers\u200a\u2014\u200ainstead of focusing on who \u201cowns\u201d any given piece of work, we are all<\/em> focused on ownership in all of its various forms. This is a broad definition\u200a\u2014\u200aas part of producing code, we\u2019re 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\u2019s 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)<\/p>\n In a more traditional team, the idea of collective code ownership comes down to how a team manages tasks<\/em>. 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\u200a\u2014\u200aand it\u2019s frequently unattainable, or hampered by subject matter expert (SME) availability. If the SME who worked on a particular code block isn\u2019t 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\u200a\u2014\u200anow 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\u2019s current code iteration. All too often, an on-call engineer receives a 2AM page for a piece of code that isn\u2019t theirs and is left scrambling to work through the\u00a0issue.<\/p>\n We\u2019ve 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\u2019ve 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\u2019s more resilient and <\/em>more welcoming\u200a\u2014\u200aexactly the qualities we were hoping to cultivate.<\/p>\n 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\u2019s <\/em>knowledge as we go. This doesn\u2019t eliminate product or technical expertise, but it does help to minimize the impact of rotating schedules and meetings that conflict with mob programming time.<\/p>\n To go back to the change experienced by individual contributors, there\u2019s 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\u2019s also much less context switching\u200a\u2014\u200awe stay with a story more consistently, and get it to the point of being ready to be deployed in less time as a\u00a0result.<\/p>\n We recognize that process changes can be intimidating, but encourage you to explore mob programming if you\u2019re looking for a way to improve team cohesion and deepen team knowledge at the same\u00a0time.<\/p>\n Here are some things you might find surprising (as we\u00a0did!):<\/p>\n 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 \u201cdeath by committee\u201d and are focused on effectively communicating to accomplish our\u00a0goals.It\u2019s totally fine to not know<\/em> 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\u00a0patternsNew 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\u200a\u2014\u200aa benefit even more valuable in our increasingly remote\u00a0world.Team members have almost never met in\u00a0person!<\/p>\n These surprises have all been good ones, for us, and we\u2019ve 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\u00a0think!<\/p>\n James Simone is a Senior Software Engineer at Salesforce, and has been featured on the Salesforce Developer Podcast<\/a>, the Developer Blog<\/a>, and also writes extensively about Salesforce development on his own blog, the Joys Of Apex<\/a>. He\u2019s passionate about Test Driven Development and, as a prior practitioner of Extreme Programming, has been extremely happy having made the move to mob programming.<\/p>\n An Intro To Mob Programming<\/a> was originally published in Salesforce Engineering<\/a> on Medium, where people are continuing the conversation by highlighting and responding to this story.<\/p>\n Read More<\/a><\/p>","protected":false},"excerpt":{"rendered":"Changes In\u00a0Process<\/h3>\n
More on How Mob Programming Affects Ownership<\/h3>\n
Closing Thoughts<\/h3>\n