Feel Like You've PARTIED With Mobbing

A new AIAF post by Tim Ottinger / Jeff Langr.

Mob programming sounds like a chaotic way of developing software: Get everyone into a room with a computer, let them have at it, and hope for the best.

Perhaps you’ve read enough about mobbing to know that there is one computer, that one person at a time operates that computer’s keyboard and mouse, and that everyone else looks at the screen and makes suggestions. You know that there are two primary roles--the person operating the keyboard (the driver) and the people deciding what to do next (the navigators). You know that you shouldn’t have the same person driving all the time.

Often teams do great with no more than that brief paragraph of guidance. Congratulations! We can assume you now know the key mechanics of mobbing.

However, some mob programming sessions run into problems, and some don’t produce as much value as you’d like in return for the many person-hours you’ve invested. To generate as much value as possible when mobbing, follow our core set of guidelines. You might even feel like you’ve PARTIED:

P: Pay down promise debt

Programming requires a lot of attention to detail. It can be a struggle to keep the big picture in mind while dealing with software architecture, various libraries, detailed requirements, and language minutiae.

As you and your mob make small changes in various places in the code to implement a feature, you can’t help but notice neighboring code that’s less than ideal. Maybe it exhibits a code smell or a potential defect. Maybe you suspect a security issue and need to check it out more fully.

How should you handle such a “distraction,” one of countless that will arise during a typical mobbing session?

• If you ignore it, you may release code that is poorly designed, reads poorly, or that has defects.
• If you work on it now, you may lose context in the work you’re trying to accomplish.
• If you try to remember it, you may forget because you’re so focused on the job at hand.

So you make a note of the concern as a piece of promise debt. Your promise debt list means you won’t have to worry about forgetting. You can avoid the distraction for now, and tackle it next time you come up for air or when you finish the current task.

We call this “promise debt” for a reason: The list consists of obligations you’ll want to pay off by the end of the mob session. Don’t pretend you’re done if you haven’t addressed all the concerns on the list one way or another.

By paying off promise debt, you honor the time your team invested in making the list, and you demonstrate respect for the code everyone works on. Your honor shows your dedication and discipline in managing the codebase. The attention helps you uncover weaknesses in the current design before they become defects.

A: Argue in code

When people talk about code in abstract terms, they often take on conflicting stances. “If we focus too much on readability,” one says, “we will sacrifice performance!” Another says, “if we make small objects, it will restrict our ability to use the values contained in them too much!”

As long as the topic is abstract and general, it is hard to come to any real understanding of what is “universally best,” since making trade-offs is context-specific. This is a core problem with abstract ideas in practical places: Our problems won’t be resolved in the abstract.

By creating an example in the code instead, and expressing it with a specific design and implementation, you shift the discussion from abstract to concrete. You focus on this code, in this case. Once the concept materializes into a real, readable thing on your monitors, you can make context-aware decisions. It’s a lot easier to reason about code you can see.

It’s okay to argue (well, “deliberate” is what we like to call it) for a few minutes. But you must agree upon specific cases if you want to make any real progress. The best specific case for you to work on is the one you’re currently on the hook to deliver. 

Allow no more than 5-10 minutes to deliberate in the abstract. Then go to the code for an answer. This prevents a lot of conversation from being wasted, keeps us focused on our work, and drives us to make agreements quickly. 

R: Rotate regularly and rapidly

The most common rookie mistake is not switching drivers often enough. When we walk in on teams trying mobbing on their own, we often see the anti-pattern of the stagnant driver: One developer, typically the team lead, commands the driver chair for an hour and more. Why? Because they’re the most senior person on the team, and seemingly things will go faster if they do all the work. Meanwhile everyone else sits back and supposedly soaks up the learning.

We’ll be blunt: Stagnant drivers usually turn mobbing into a snoozefest. We tend to refer to this pattern as the “worker / rester” pattern, or when it’s not quite as awful we may call it “worker / watcher.” 

Instead, make the session lively and keep everyone engaged by rapidly rotating. A five-minute rotation seems nuts--what can one person possibly accomplish in five minutes? You’ll find out, however, that short rotations:

• Keep everyone engaged and focused on the task at hand
• Avoid dominance by the senior devs
• Minimize the sweat-factor of being in the hot seat

Driver sessions of 5-10 minutes seem perfectly in line with our recommendation for deliberation limits.

Rapid rotations are a must for successful mob-programming! Download Mobster now and use it.

T: Track waste and other learnings 

When asked “what is mob programming good for?,” most people will list shared learning as the primary benefit.

How do they know? Are we sure that teams are learning, sharing, and participating together when mob programming?

Agile teams have long used Big Visible Charts (BVCs) for making their work visible and transparent to anyone who visits the team space. When mob programming, we will often track our daily learnings or questions on a flip chart.

This has a number of advantages:

• When someone records an item, you are aware that learning has happened.
• You can count items on the chart as evidence of the efficacy of mob programming.
• You can bring charts to the retrospective and reflect on knowledge acquired and problems solved.
• You’ll have reminders of tricks you learned yesterday or the day before, easily and eventually forgotten otherwise.
• People not present when the learning took place can review the new additions and ask questions.
• When problems are listed on the BVC, their presence will prompt you to solve them.
• Sometimes you become aware of blind spots or knowledge deficiencies, and are reminded by the chart to put some time into research.
• You can visit teams that similarly radiate their learnings in order to glean new ideas. This can spice up community-of-practice meetings (guilds, scrum-of-scrums, etc).

Tracking knowledge acquisition isn’t a universal practice for mob-programming teams, but we’ve found it so helpful that we recommend it for all teams, especially those new to the practice.

I: Intermittent breaks

When things aren’t going well in a mob programming session (yes, it will happen), sometimes the best thing you can do is get up and walk away for ten minutes (or even better--walk for ten minutes, perhaps around the building). Sometimes the best thing is for the whole team to stand up and disperse. Clear heads will often return a better solution to the mob.

When things are going well in a mob programming session, it’s easy to press each other to keep going. We’ve been in mob sessions that might have lasted all day without a break if we didn’t insist on one.

Humans need breaks, and they work better with them. Feeling sleepy, distracted, sluggish, frustrated, stupid?

Get up and take a short walk from time to time. Don’t worry, the mob will survive in your absence! 

Alternatively, take regular whole-mob breaks at least once every 90 minutes, and don’t let your teammates talk you out of them (trust us, it’s easy to do). Mobster will help force the issue.

E: Express intent

The goal of a navigator is to provide direction and guidance, not to micromanage: “Turn left here; now put your foot on the gas. Brake! OK, ease out slowly…” Or, “Put your cursor here, now right-click, pick the third option. Okay, now click here. Now go to the other file, and click here. Right-click, I mean. Yeah, now pick the middle option, then type OJK… select the third word.”

Back-seat drivers frustrate everyone--driver and rest of the mob included. Rote directions are hard to follow. The driver and others in the mob find it impossible to correct or interject any ideas because they’re completely caught up in trying to figure out what the hell you’re asking the driver to do.

Instead, provide direction. “Let’s create a test that verifies the system rejects adding duplicate requests.” The driver can ask for guidance on specifics as needed.

Yes, at times the driver will need to ask for precise steps. Consider this driver’s ed, something that all drivers will experience intermittently. We want everyone to improve, so listen and learn to ingrain the new bits of learning that will come frequently. Mob nirvana is when we’ve learned to minimize detailed directions and focus instead on relating end goals.

If mob programming is (in Josh Kerievsky’s words) a continuous integration of ideas, then expressing actions rather than intent is the primitive obsession of mob-programming. 

Don’t leave your partners guessing.

D: Driver doesn't navigate

The other most common mob-programming anti-pattern (along with stagnant drivers) is dominant drivers--people who “run away” with the code while at the keyboard. A heads-down driver choosing where to go and how to get there is going to bore the tears out of the mob--they’ll eventually fall asleep (sometimes literally) in the back seat. 

More importantly, the mob will learn little from the driver and the driver will learn nothing from the mob.

To prevent runaway drivers, follow the rule of strong-style pairing: The driver isn’t allowed to decide where to go next. Instead, the mob makes navigation choices and relays them to the driver. The driver’s job is to listen and translate these directions into code. A driver who wants to head in a different direction must relinquish the driver’s seat.

It’s not hard for drivers to get carried away and start to “run away,” but they’ll usually not take offense if you remind them of the rule. Often they’ll even admit their breach and ask if they should just revert.

Newbies (new programmers, new team members, people new to the system) of all stripes are naturally intimidated by the prospect of being in the hot seat. Strong-style pairing minimizes the fear factor: The newbie isn’t expected to know what to do, and the mob is always more than willing to help them shift into higher gears.

Not only does strong-style pairing improve the capabilities of everyone on the team, it helps them improve their ability to communicate ideas about code and design.

Despite the name, mobs aren’t free-for-alls. A mob session is best treated as a focused journey that you keep on course by following our tips.

Sources

Industrial Logic. “A Few Tips for Mob Programming,” https://www.industriallogic.com/blog/a-few-tips-for-mob-programming/ 

Langr, Jeff. “Two Rules for MobbingSuccess,” http://www.ranorex.com/blog/two-rules-mobbing-success/