Getting Mob Programming Buy-In at Your Organization

Repost of https://simpleprogrammer.com/mob-programming/.

This piece was a collaboration written by Nate Wixom and Torrey Powell.
This piece was a collaboration written by Nate Wixom and Torrey Powell.

Mob programming is the best approach for many development applications. Mob projects result in a more finished project at release, with fewer bugs. By focusing on one project at a time, teams can complete projects more efficiently, and those projects are higher quality, requiring fewer revisions.

The Project Management Institute’s 2017 Pulse of the Profession survey reports that 71 percent of organizations now use agile methods to complete projects. Included among agile approaches is mob programming, defined by the Agile Alliance as “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.” Picture multiple engineers at one station working collaboratively on one project.

While many organizations have adopted mob programming as a core part of their development skill set, not all development organizations have bought in.

Still, to implement mob programming successfully, you need buy-in from two important groups at your organization—the executive team and the programmers themselves.

By following the strategies below, you can get organization buy-in for mob programming from top to bottom and start using this agile development methodology to provide superior finished products for clients both inside and outside your organization.

Getting Buy-in From Leadership

As far back as 2000, the benefits of developers teaming up on projects to solve problems have been evaluated against the performance of individuals. An oft-cited joint study between the University of North Carolina and the University of Utah showed that paired programmers were 15 percent more successful in solving problems and that their solutions did so with fewer lines of code.

That may not be an impressive enough statistic for senior leadership, however. Shouldn’t it be at least 100 percent more efficient in order to be cost-effective?

The truth of the matter is that such small efficiency gains in the short run may not be convincing. It’s a long game, and you’ll need to open leadership’s eyes to the possibilities of multiple projects spanning months, even years.

If you can get leadership to agree to a six- to 12-month trial for mob programming, here are some of the benefits your organization will see:

  • Fully inventoried projects: With groups working more thoroughly and quickly on fewer projects, projects are less likely to be abandoned or forgotten, and more projects are fully completed. More eyes on every project means projects are more complete when they are released to the world.
  • Shorter turnaround on projects: Projects are completed quicker than when worked on by individual developers. With more eyes on each project, roadblocks are more easily overcome, and solutions to problems can quickly be brainstormed.
  • Fewer issues in live projects: As the projects are fully inventoried with more people reviewing every line of code, fewer bugs make it to the production environment. With individual developers working on projects, it’s often understood that there will be bugs that need to be fixed while a platform is live. You can eliminate a lot of this necessary rework through mob programming.
  • Quicker onboarding for programmers: Onboarding into a mob programming environment is more efficient, as you can drop new developers right into a mob that’s already at work on a project and get them contributing immediately rather than having to divert resources for training and management of new programmers’ early projects with your organization.

Over time, mob programming improves efficiency not only in the completion of successful projects but also in the integration of new team members. You may not see the return on investment right away, but over time, it will be evident.

Better results, faster, with fewer abandoned projects—that’s something any senior leader can get behind.

Getting Buy-in From Programmers, Developers, and Engineers

Getting buy-in from senior leadership is one thing. Getting buy-in from the people who will actually be doing the mob programming is something else entirely.
Getting buy-in from senior leadership is one thing. Getting buy-in from the people who will actually be doing the mob programming is something else entirely.

Many engineers, developers, and programmers are used to working alone—putting on the headphones and sitting down to crank out code, cut off from the outside world, for hours at a time. How do you get people who are used to working alone to be active participants in a group environment where the major reason for increased success is teamwork?

In our experience, having gone through many iterations of mob programming while integrating it into the organization at Clearlink, not everyone is a good fit for mob programming—but many more than you would expect actually are, once they are involved.

Why is that? Believe it or not, engineers like socializing with their colleagues, they just haven’t always had the chance to do so. Once they realize the level of engagement and the quality of code that is created while working collaboratively, job satisfaction increases, learning increases, and enhanced team bonding occurs. Mob programming is also a meritocracy where the best idea wins, and everyone in the mob has an equal voice—from the most senior developer on the team down to the newest arrival.

Each mob contains two roles: the driver and the navigator(s). The driver sits at the computer, inputting the code, while the navigators tell the driver what to type. These roles switch in the mob at regular eight to 15-minute intervals, giving everyone an equal chance to drive and to navigate.

Everyone remains actively involved in the process, with ideas being shared and implemented quickly. Since everyone gets a chance to navigate, junior programmers gain confidence by asserting their ideas.

We recommend, either at the completion of a project or at the end of each workweek, recognizing mob team members for their contributions to the project(s) they have worked on. Also, allow programmers to share what they learned and what they had trouble with. After a few projects and a few of these recognition and retrospective meetings, your team members will be comfortable working together and fully integrated into the mob programming mindset.

Making the Jump

Changing development work from an individual to a mob programming style can be a big leap—one that can result in a few stumbles along the way. But once you get buy-in from leadership for a trial and can get some programmers on board, you’ll see how it can benefit your organization.

We’ve given you some navigation—so get ready to drive.

Denis Trofimov
Denis Trofimov
Lead Platform Engineer

Lead Cloud Platform Developer. I enjoy creating Kubernetes Operators and such :)