Mob Programming

Six years ago I was searching for a way to get teams to increase quality and value delivery when I stumbled across a poorly filmed YouTube video of a software development team doing something unusual…

This team was reporting something nearly mythical: they went 18 months without a production bug while increasing their productivity by TEN TIMES. Naturally, I was skeptical.

When I watched the video, what I saw was amazing: a team working TOGETHER. All five or six of them crafting the same piece of code at the same time.

I immediately assumed what most people do: they must be terribly slow, inefficient, and expensive.

But, I was so intrigued by the high quality and productivity increase I wanted to give it a shot. So, we spun up a new team and helped them work in a way similar to what we’d seen in the video.

After ONE SPRINT we recognized that working this way was better than what we had been doing, and we worked like that for the next five years and scaled the practice to a dozen distributed teams.

When I started a new job last summer and introduced Mob Programming to my team, they were skeptical, too. True to form, some people saw the value right away. Since the team was fairly large, we quickly moved to two smaller “workstream” mobs, and the teams knocked out a mountain of work in a low-stress, continuous flow over the next several months.

Looking at the diagram, along the horizontal axis I have the different styles of development ordered by the intensity felt by a team member who has experience with each situation.

The lines on the chart compare the Assumed Speed, Productivity, Value Delivery, Safety, Quality, and Efficiency against the Actual value of those qualities for each style of working.

If this seems counterintuitive, you are not alone. Nearly everyone, including me, thinks this just can’t be true until they try it.

Mob Programming is simply defined as “All the brilliant minds working on the same thing at the same time in the same space on the same computer.”

When first starting, it’s common to use the Driver / Navigator pattern which is summarized as: “For an idea to make it into the code, it must go through someone else’s hands.”

Everyone else in the room, or on the call is “in the mob” and communicates through the navigator.

It’s not uncommon for this style of work to take some getting used to. That’s OK! The more we work together, the better we get at doing it.

Soon, you’ll start to make realizations like “We’re not in school anymore; Our leaders actually want us to cheat off each other!”

Other benefits beyond safety in numbers include:

• Instant code refactoring
• Instant code review
• Instant knowledge sharing
• Instant “buy-in”

Meanwhile, the rest of the mob is doing things like:

• Considering the bigger picture
• Thinking of next steps
• Keeping track of the to-do list
• Thinking systematically
• Answering team chats and emails
• Researching problems
• Looking up documentation
• Updating story status in the tracker
• And most of all…learning, collaborating, having fun, and getting bought in.

As we neared our first pilot last December, we started working with several other teams in a more intense Swarming model, and it was clear that the time we spent mobbing allowed our team to quickly adapt to working with new team members. It might sound small, but it made me proud when I saw my team's members be the first to offer to share their screen. Also, they’d be the first to offer to navigate someone from another team through an unfamiliar area of the code!

So, I encourage you to learn more about Mob Programming and to give it a try for one sprint. Change is the only constant. You’ll find you’ll like it better than all the other styles of working. And your leaders and stakeholders will love it, too! As always, feel free to reach out to me with questions. Lastly, thank you to my team for their courage, open-mindedness, honesty, and willingness to continuously improve. #TogetherWeWill