BROADCASTS.com

Published: Oct. 7, 2019, 11:59 p.m.

Mob Programming with Chris S.

Chris Spoehr, Performance Manager and Mob Programming Expert

 

Mob Programming Maxims

The team I'm currently on has been trying mob programming for about 4 months now. Recently, I was privileged to attend the first Mob Programming Conference. At the conference, both Woody Zuill and Llewellyn Falco gave compelling keynotes. When I returned to work, my team and I wanted to get the most out of my insights and we quickly began talking about how to level up our mobbing.

We came up with an idea to introduce a third designated, rotating role to our mob when it was large enough. (Our mob flexes in size from 3-6 people.) After driving, a mobster would take on the role of 'facilitator' to observe _how_ the mob was working, and coach the mob when needed. In order to define just what these collaborative ideals are, I compiled these Mob Programming Maxims from my conference notes and slides Woody and Llewellyn have posted online. There is some affinity grouping, but no importance in the ordering. The commentary under each maxim is my interpretation of the meaning and relevance of the maxim.

* For an idea to go from someone’s head into the computer it must go through someone else’s hands. - Llewellyn Falco

This critical mindset behind mob programming comes from Llwellyn's "Strong Style Pair Programming". Working this way forces us to communicate clearly and completely with our teammates. When we're doing this well, this communication is at an abstraction layer. It helps build a shared mental model of the code amongst everyone on the team.

* Turn up the good – Woody Zuill

This concept has such depth that it deserves blog posts of its own. The core idea is one of positivity: instead of potentially applying the wrong fix to the right problem or the right fix to the wrong problem, we take something we're doing well and focus on doing it even better. As we do this, a common side effect is removing base conditions that created an issue in the first place, and those issues 'fall away.'

* Just try it. It’s in the doing that we learn. – Woody Zuill & Llewellyn Falco

One of the strengths of the mob comes from the breadth of ideas that comes from having "all the brilliant people working on the same problem at the same time." Often we will need to discuss how to solve the next issue in front of us. When we do, we discuss it only long enough so everyone understands the different approaches we can take. We bias ourselves toward action. We stop short of debating the merits of each approach. Just code it. We see how each approach looks in code. Then, we decide on which approach to keep, or we may discover a third, better approach has emerged.

* Ask for Trust – Llewellyn Falco

We ask of each person in the mob that they trust we will try everyone's ideas in turn. This is especially vital in a newly formed mob where this trust hasn't been built through experience. Without this trust in place, thrashing can occur. This kind of trust is reinforced by following the "just try it" maxim.

* Respect Each Other

This is another way of saying we should treat each other with "kindness, consideration, and respect", as Woody and the team at Hunter agreed to do. We take the Retrospective Prime Directive to heart and assume our teammates are contributing their best. And we're also all people. Many of us developers might not consider ourselves great at soft-skills, but it doesn't take much to not be an asshole.

* Respect The Code

If we're working on existing code, we should apply the Retrospective Prime Directive to the code itself. It was the best code that could be written by those who wrote at the time they coded it. Even though we may know so much better now, belittling the code (and those who wrote it) doesn't move us forward. However, this doesn't mean not refactoring or rewriting the code. We do need to respect it enough to understand its intention.

* Be prepared to contribute the right thing, at the right time, in the right way – Woody Zuill

When we are in the mob, we should all be prepared to contribute. This may manifest through navigating or driving. It may also manifest through doing research as a navigator to look up the API documentation the mob needs. We are mobbing because we are all valuable to the work being done. We should commit our focus to that work.

A key aspect of this maxim is to *resist over-contributing*. We must practice the art of not talking to allow space for others to contribute. Using the single-navigator style of mobbing, where only one team member at a time acts to navigate the driver, while the rest silently observe until their turn, helps to reinforce this skill.

* Communicate so the driver understands * Intent * Location * Instruction

As navigators, we want to communicate with our driver at the highest possible level of abstraction. We want to start by communicating the intent of what should be done next, "we need to call the backend to get a list of possible widgets." Only if the driver needs further explanation do we drop down to location, "On line 123 we have a service object that we can call." Lastly, we may sometimes need to give specific instructions to a particular driver, "On line 123, type: var widgets = service.getWidgets();." This may be needed for a new dev or even just new to the tech stack.

* Once the driver understands intent, navigator(s) may move on.

We trust that once our driver understands our intention, we as navigators can start talking about what's next. Getting good at working this way allows us to see the full benefits of the group's collective knowledge and collaboration.

* Rotate as often as is beneficial

We want to rotate often enough to keep everyone engaged in the work we're doing. We prefer shorter rotation times. In fact, the quicker the rotation time the better the mob has to be at switching. Short rotation times also encourage turning up the good on the other mob programming maxims.

There is no one-size-fits-all rotation time. Through experimentation and talking to others at the Mob Programming Conference, our team has discovered that "everyone drives at least once per hour" is a fair heuristic. Our team even added to it to prefer 10 minutes or shorter rotations.

* Take Breaks

When mobbing its easy to not take breaks. We can get into a groove and lose track of time. Or we might think about taking a break but no one else seems to need one so we don't speak up. Part of keeping our workspace comfortable is making sure we take time to physically stretch and rest our minds. Don't be afraid to call for bio breaks.

I hope having these Mob Programming Maxims consolidated in one place helps your mobbing. I look forward to continuing this conversation as we discover more about this new way of working.