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 w