How I learned to stop worrying and love the Mob
So, you’re leading an engineering team and want to have some tips about how to do mob programming effectively.
Or, you’re already mobbing, but have run into some trouble spots. Or for whatever reason you just want to compare notes.
This article is for mobbing at any level.
TL;DR
I’m going to talk about how you can effectively lead a single team in Mob programming.
The following are the section headings of this article. As a TL;DR feel free to treat the list of “Techniques” as a menu of things to try.
Background ← you can skip this if time-pressed
- Apophasis
- How it happened for me…
Key Principles ← I find this to be the essential glue
- Be an excellent facilitator
- Value Diversity: Work with what you got
- Keep it positive
Techniques ← make these into cards, shuffle the deck & use one!
- All the existing Agile tools retrofitted to mob-style
- All the existing Communication tools, retrofitted to the mob
- All the existing Pairing tools
- AnytimeRetro
- Call out positive contributions
- Dedicated hardware
- Don’t Mob
- Facilitator role
- Mob with another mob
- Parallel Play
- Pomodoro Technique
- Remote Mob
- Rotate Roles
- Scout
- Try to mob on anything
Concluding Rant
Background
Apophasis*
[*] In this article, I’m not going to talk about the fast feedback loops, dynamism, transparency, improved quality, team alignment, cohesion, quick leveling up, knowledge sharing, the profound impact on DevOps preparedness, paradoxical speed-through-single-stream-of-work, the leveraging of various skills in one place to blaze through issues, the fun nor even, how it helps us work better together. You get it. You’re just here looking for practical advice on mobbing, not a rehash of what Mob programming is and why it’s a good idea. So I’m not going to talk about that.
How it happened for me…
Instead I’m going to talk about some of my takeaways after 1 year and 4 mobs at Meetup.
Thanks to the work of many, but in particular,
, a former Engineering Manager at Meetup, Pairing as a practice was already made vibrant at Meetup. And just like in real life everywhere, an ad-hoc “mob” might happen anywhere, especially around an on-call issue or difficult question. So Meetup, being a platform for folks to meet up IRL, was already accustomed to some aspects of social coding.I was the engineering lead of a team called “Platform Services Classic,” which tasked with isolating and making tractable the tangly and reviled 17-year old legacy monolith.
We were dealing with some hairy issue, when I think it was Tyler Beebe (sorry if it was you,
) who said,“let’s mob on it”
Just prior, I had noticed the familiar uh-hey-er-we-should-really-sync-up-on-this look from Doug Tangren. So the whole team naturally jumped on the bandwagon.
After a notably vibrant and productive session, we did a quick end-of-day retro about whether to continue mobbing the next day.
“Yeah!!”
was the unanimous sentiment.
3 teams and 4 mobs later: several teams at Meetup now mob by default daily, while the remaining pair by default.
Key Principles
Since we started mobbing, a number of engineer leads have expressed some interest or tried mobbing, but have also had a number of stumbling blocks. As a result, I’ve collected these thoughts on leading the mob.
Be an excellent facilitator
If you’re lucky, it’ll just happen without a hitch. But just in case, be prepared to be an excellent facilitator.
That is, troubleshoot the team every minute. Are people getting frustrated? Is someone feeling that their opinion isn’t being heard? Are you not hitting an effective flow and releasing high quality rapidly?
An excellent facilitator may need to set up the framework or ground rules, and direct the flow, at first. Actively curate your Mob structure(s) to promote positive collaboration, psychological safety, and good engineering practices. Use what you know. Model facilitation techniques (check out Lara Hogan or other resources you can find about on this).
Consider the specific and real people you have on your team and sensitively use the processes and techniques you’ve learned as a software engineer, leader, manager, or agile coach. Then let the mob take it over, as soon as you possibly can so you can just be an ordinary member of the mob.
As the lead, you’ll need to introduce the process when needed. But soon, your team should start doing the same. Part of the cross-training you get out of mobbing is also the leadership training your team gets.
Value Diversity: Work with what you got
Be like water. Every person is different*, so you’ll need to be fluid and creative rather than force some robotic or tyrannical behavioral social norm that exists only in your head.
There is no “ideal” make up to the mob. Luckily**, I’ve been in great mobs with those in their early 20s to late 40s, with at least 3 genders, and with a diverse ethnic and economic background.
Our differences are not a problem, but rather a powerful capability that help us overcome the diversity of problems we encounter in the art of practical engineering.
Asides:
[*] Again,
[**] Meetup has been a great champion of diversity, what has made it surprisingly resilient in the face of rapid change.
Keep it positive
Cultivate kindness. We are doing Social Coding here. So, be a social engineer.
Love your team mates because they are lovable. Everyone has strengths and weakness. Foster a culture that emphasizes the strengths of others. Celebrate them by being surprised and grateful. In return you’ll quickly catch oversights and blind-spots better than any pair or solo engineer and will release a well-rounded product.
Cultivate trust and safety*. Safe and fulfilled people will bring their best most engaged and creative selves to the team. This is exactly what we need when tackling complexity, then operating and maintaining the systems that we write and that we have inherited.
Asides:
[*] See Google’s Tool: Foster Psychological Safety.
Techniques
Troubleshoot every minute: Some tools to use
Here’s an alphabetical list of tools you can use to address rough patches you come across in your mobs. You could even shuffle these into a set of playing cards and flip through them to consider if you want to play just one card today.
All the existing Agile tools retrofitted to mob-style
Each of these could be a separate “card” you play. Since these are less specific to mob programming, I only mention them: Kanban Boards, Lean, Write small Stories, Standups, Retrospectives, Post Mortems, the Prime Directive, Lean Coffees, IPMs are all tools with plenty of history and utility. Use them judiciously and just as importantly, stop using what becomes no longer useful. E.g. some mobs might find you need less ceremony with fewer tickets since much is captured in conversation. Others might double-down on writing tickets together as a way to capture work and remember what they agreed to.
All the existing Communication tools, retrofitted to the mob
Remember to get on the same page with whiteboard conversation. Gather feedback outside the mob or simply have another shared visualization with PRs. Manage Slack by minimizing interruptions, or block off time to respond to DMs and email, or sometimes lean into them with the mob!
All the existing Pairing tools
You can copy/alter any tools you want from the Pairing world, Driver/Navigator is a key one, where the mob has 1 driver and many navigators.
I’ve also seen a limited use of Ping Pong as a way to get things started. Particularly in making the transition from paring to the mob.
AnytimeRetro
The team feedback cycle can be up-to-the-minute in a mob. At the end of every day, it’s useful to go around the circle and ask each member for “pluses and minuses.” That is, one thing that went right and one thing that went wrong. Then decide on how to handle the minuses and how to reinforce the pluses. This can take as long as 5 minutes.
Once you’ve established safe feedback with this practice, run this card any time something is going off-the-rails and you want to nip it in the bud. You can do it at the end of the day, at the end of the POM (see “Pomodoro Technique” below), or in extreme cases, just stop the mob immediately and run a 5-minute Retro — (bonus card: “gut check: does everyone just need to get ice cream and come back?”)
Call out positive contributions
Remember to keep things positive and acknowledge the good work that your team is doing. This is easy. “That was a good idea.” Done. When you describe what you did in standup, acknowledge their contribution in public, “We made progress on feature X, since Georgette came up with the idea that we do Y”. Done. Not only is honoring people’s work the right thing to do, but you’ll often find that there will be a virtuous circle of positive communication of this type reverberating in your group. Everyone starts giving each other props!
Dedicated hardware
You don’t need to put the cart before the horse. You don’t need to buy stuff on day one. But, it is very useful to have a dedicated mob station with multiple screens and keyboards.
We have a station set up with a dedicated team Mac-mini and 2 shared screens facing opposite directions on a long bench so that 2 sets of engineers can face each other*. For remote mobbing, we all have the same high-quality headsets (integrated mic+headphones). Common hardware helps encourage a safe and efficient space with a shared, configured, predictable set of tools, IDEs, and key bindings, in an agreed-upon environment.
[*] Thanks to our director,
, for suggesting and then getting the company to buy these for us.Don’t Mob
Just like any technique, process, paradigm or framework, mature use of that technique means judicious use of it. Sometimes you just need to not mob. Accommodate cognitive diversity and different levels of social coding experience by pulling back when you need to.
On my team, we mob by default, but 2 times a week we scheduled 2-hour blocks of “solo-flight.”
My only caution to this would be: if the team hasn’t yet built up the skill of mobbing effectively, try to commit at least a month to mobbing exclusively. You need to build the mobbing muscle before can back away from it effectively.
Facilitator role
Some mobs in the storming phase of team development will find it hard to resolve differences between equal but opposite approaches, styles, or find they get sidetracked by a desire for micro-improvements, frustration with key-bindings, or Slack. Maybe you have someone who’s “grabby” with the keyboard, or any number of distractions. At this point, it’s good to introduce the “Facilitator” role. The facilitator is in charge of a small handful of duties (3–5) like “Driver Defender” so no one besides the designated driver is allowed to grab the keyboard), “Focus Keeper” to stop side-tracking from the task at hand — perhaps by capturing the concerns on a whiteboard that “don’t need to be worked on right now” — or by assigning a “lead navigator.” The facilitator will quickly arbitrate and keep the group on task. This role should rotate, but as lead, it’s helpful for you to model what you’re looking for by being the 1st in the role, or much better, assign someone else from the team that you know will be a good at it.
Mob with another mob
Other teams may be mobbing or not. But when you have interacting services or need to implement a feature request from another team or vice-versa, invite 1 or more of them into your mob!
It can be a mirror that re-enforces to the mob how well they are collaborating or really illustrate the positive impact their work is making for the other team. Another team can often introduce your team to other new ways of thinking.
When inviting another team, I always make sure to start with a good facilitator, whiteboard tasks, and asking members from the guest team to “drive” the keyboard. This is like serving your guests at the dinner table first and it quickly integrates the guest team.
If your mob isn’t yet norming or performing, you’ll want to manage this carefully. Sometimes I’ll ask for fewer members of the guest team to join or curate the interaction in some way. Do what you need to keep your team psychologically safe! At other times I’ll let the experiment reveal itself.
Parallel Play
I like to use this term for our scatter/gather technique.
That is, you’ll find that certain tasks like reading documentation can be awkward in the Mob. Or, maybe you’re finding it hard to work out an agreed-upon approach to a problem between good alternatives. Or, sometimes even if your team normally flows, people just need space.
When this happens: Agree to do a POM or two apart (see “Pomodoro Technique” below), with the plan to come together to review each other’s findings, with the goal of integrating them back into the mob.
My team mobs by default every day, but we dedicate several hours two afternoons a week for “solo flight,” to give honor for diverse tasks, interests, and individual creative outlets in addressing our planned work from the prioritized backlog.
Pomodoro Technique
Pomodoro is also extremely useful. Like pairing, most people find it is exhausting interacting with people all day long. “POM” force you take much-needed breaks and really do work to refresh the mind and tempers. Don’t be rigid though. My current team likes 30-minute POMs, with 5-minute breaks. I’ve worked with others that like to keep focus for 1 hour at a time. We use the app, Focus, installed on our mob station, laptop and phones. Another team at Meetup like to use MobTime which features a reminder for named driver-rotation! There are many many alternatives to choose from.
Remote Mob
People who have discovered that mobbing works for their team IRL often find working in distributed teams especially challenging. However, we have found this to be relatively easy to overcome.
Two tools from this list are especially important to make this work: Dedicated hardware (above in this section) and Mob with another mob (below).
For occasional remote members, we join our mob station to a Zoom conference and ask those IRL to bring our laptops to the station and join the Zoom with the same quality headset (mic+headphones) that our remote employees do. Once you’ve established IRL practice, this works remarkably well.
For a full-time hybrid remote plus IRL team that mob everyday, instead of headphones, we use a high-quality conference speaker/mic, shift the position of the camera often, and have multiple monitors positioned that we can face both the screen and each other.
Rotate Roles
Don’t let anyone get pigeonholed. It inhibits learning and takes away from some of the gains of mob programming. That is, you build empathy, resiliency, plasticity, exposure, and growth when mobbing. Let this happen, even when some people are “not good at it.” We usually rotate some aspect of they mob every POM.
Scout
This is like parallel play, but instead of the whole team simply have one person break off to do a spike, Proof-of-Concept, troubleshoot, or research a problematic area blocking the mob. They then bring their findings back within a time-boxed effort.
This is useful when you need to give one of your introverts on the team a break or if you have a competing priority that simply must be handled, but you don’t want to make the team lose momentum on your main line of work.
Try to mob on anything
Once you discover the power of mob program you might be tempted to try it. Not just on programming tasks, but almost everything. I highly encourage this. We mob on everything and anything. I have yet to find any task that hasn’t benefited. We mob on writing tickets, planning projects, for on-call issues, stakeholder interactions, PRs, interviews, presentation slides, and, of course, lunch. It turns out that extreme collaboration and focus is a powerful, reusable component to build on your team!
Concluding Rant
The problems of software engineering have fundamentally changed since the early 21st century.
The turn-of-the-millennium began with the highly caffeinated lone anti-social “rock stars” delivering too much too clever inscrutable code that only he (sadly, “he” is still the over-majority pronoun) could maintain. Valuing overly technical/mechanical thinking and lack of cognitive diversity created terrible UX and pre-cursed Dr. Strangelove-like failures similar to not having female crash dummies and Facebook depression.
From today’s lens, the proliferation of distributed systems in the day-to-day programmer’s life, a greater complexity of ecosystems, architectures, domains, remote working, outsourcing, the transiency of goals and teams, dynamic global interaction, all make Social Coding practices like Mobbing invaluable.
The social craft of coding makes difficult systems tractable. It helps us to understand and maintain complex systems pooling together our mental perspectives and interpretations.
Perhaps more importantly, by working together with a diversity of engineers, the design of our software tends to reflect and work for the diversity of humanity that our systems seek to serve.
Coding/Development/Engineering is a social endeavor. It is a human endeavor. Both in the product you create and even in the in-the-moment process of creating it, software has a decidedly social impact.
It effects in the world, your company, your teammates, and you.
So, as a facilitator of the Mob: If you cultivate kindness, trust and safety, and diversity, you will see it immediately reflected in the world around you every day you come to work.
P.S. Props to my most recent mob-mates: Tyler Beebe,
, and Anna Armentrout. Thank you for the daily lessons. Mob rule!