(This post is part 3 in New Relic’s 6-part mob programming series, which we call Taming the Mob. Maureen Dugan, a software engineer on the Account Experience team, contributed to this post. )
Hopefully, you’ve been following our mob programming series in which we’ve shared the basics of mobbing: three to six engineers around a table, writing code on a single computer. This model has helped various teams at New Relic make huge gains in efficiency. Teams enjoy increased focus, create fewer bugs, and have tighter feedback loops than ever before.
And now it’s time to help you get started mobbing.
First things first: write your team’s working agreement
Before you host your first mob session, create your mob’s working agreement. For mob programming to work, it’s essential that the entire team trusts each other. When your relationships with your colleagues are built on trust, you’re much more likely to acknowledge gaps in your knowledge, mentor each other, and collaborate more efficiently. When there is trust on a team, individual members feel more empowered and less vulnerable. Trust also lays the groundwork for authentic retrospectives, which are essential for a mob’s success (as we’ll discuss later).
When I first mobbed, I did it without much intention—or so I thought. Really, it was my team’s culture, I think, that influenced our success. When we started mobbing, we first took time to discuss team expectations, which I think had a significant influence on helping us create a successful mob.
At New Relic we formulate team expectations in the form of working agreements, as described in “Liftoff: Launching Agile Teams & Projects” by Diana Larsen and Ashley Nies. According to Larsen and Nies, working agreements
- Complete the sentence “We work together best when __.”
- Are limited to seven agreements.
- Describe “how we want to do things around here” on a daily basis.
- Have everyone’s buy-in.
- Are aspirational and do not codify anything that is already habit.
In my team’s first working agreement, we said, “We work together best when we shorten the feedback loop for work in progress.” The agreement didn’t prescribe how we would accomplish this; instead, we relied on the mob to perform code reviews as a group, and found this was extremely effective in cutting down our feedback loop.
Later, when we added “Limit work in progress” to our agreement, the mob ensured we could start a second task only if the first task was truly blocked. And once we realized we needed an agreement on conflict, we wrote the following statement: “We want conflicting opinions to surface quickly, and be heard, so that we can make a decision and avoid getting sidetracked.”
Working agreements are living documents. Our team holds weekly retrospectives to help determine if we’re meeting our own expectations. Occasionally achievements allow us to remove aspirational items from our agreement, but we maintain documentation on regular practices, which is especially useful for onboarding new engineers. This living document helps facilitate our mob and keep it productive.
Review some pull requests together
Once you’ve written your team’s working agreement, consider reviewing some pull requests (PRs) in your first mob session—this is a great way for your mob to get its feet wet. Reviewing PRs in a group setting encourages conversations about design and coding standards. You may even find ways to improve your working agreements.
When the mob is ready to code…
OK, so you’ve written your working agreement, and your mob has done some PR reviews. Now the mob is ready for its first coding session. You may find these 10 guidelines useful:
- Find a working environment where everyone is comfortable.
- Find a whiteboard and write a list of tasks the mob will work on, and ensure the list is always visible. Check in with the list between rotations to ensure the group is focused on the task at hand.
- Designate the first driver (the engineer who’ll run the keyboard) and the first navigator (the engineer who’ll verbally describe what the code should do).
- Set a timer for 5-15 minutes, depending on the type of work you’re doing. If the group is familiar with the language and framework, err on the shorter side. Give longer durations for less-familiar territory.
- Pause the timer during discussions to ensure drivers get their fair share of time at the keyboard.
- Once time is up, designate a new driver; the previous driver becomes the navigator.
- Avoid having more than one laptop open at a time. (Note that some mobs use a single laptop while others allow members, who may prefer their own customized text editors, to use their own laptops while driving and push to a shared upstream branch.)
- Avoid the “mob smell”: This occurs when a mob member works independently and wants to show the group their screen. In these situations, they’ve almost always lost the contextual thread of the mob and have just become another problem for the team to deal with, kind of like a code smell.
- Allow any member of the group to step away at any time. Giving team members the freedom to step away from the mob to deal with outside distractions helps the rest of the mob maintain focus.
- To determine when to give breaks, consider the Pomodoro Technique in which you typically work in 20-25 minute intervals separated by short rests.
Embrace the retrospective
A crucial part of mob programming is holding retrospectives. Whether your team desires an organic or more structured retrospective, keep the following guidelines in mind:
- Have an informal conversation after the mob session about what the team liked or didn’t like. Ask yourselves what worked well for the mob and what didn’t.
- Use an Agile-style retrospective.
- For a scientific approach, gather data after each session, such as rotation period, total duration, break length, and overall rating—and look for trends.
- Rate your team after each session for a simpler approach.
Retrospectives will help you identify ways to make mob programming an effective and fun work environment.
When the time is right, upgrade your mob
Once your mob has a good rhythm going, consider adding a notetaker. A notetaker can capture key decisions your mob makes about your backlog, changelog, and working agreements. Documenting key decisions can reduce “FOMO” (fear of missing out) if someone misses a mob session, and it can also help onboard new members.
Your mob may also consider adopting task management software, such as JIRA, to track your work. This can be a good way to communicate and maintain transparency with your engineering manager, product manager, and any executives who may not otherwise have insight into your work.
Don’t miss the other posts in our Taming the Mob series:
- Part 1: An Introduction to Mob Programming
- Part 2: Mob Programming Is Like Tending a Campfire
- Part 3: How to Start Mob Programming
- Part 4: Tips and Tricks for Effective Mob Programming
Editor’s Note: As part of our work with mob programming, we recently held a FutureTalk meetup in our Portland offices on the topic. In the video below, you can see presentations by Platform Software Engineer Maureen Dugan on “What Is Mob Programming,” Lead Software Engineer Cory Johannsen on “Why Mob Programming Works: Trust, Buy-In, and Vertical Ownership” (21:00), and Software Engineer Caito Scherr on “Mob Strategies” (54:00).