Make Collaboration Consistent: The Case for Mob Programming
At AdHawk, we’ve been a pairing-focused, remote-first engineering team since the original crew graduated from the Techstars Boulder accelerator back in the fall of 2015. As we’ve learned a lot about growing a technical team with many lessons along the way, we’ve had to iterate our development process.
We grew from a handful of engineers to many dozens of product team members in just a few short years. One recent helpful pattern a few AdHawk development teams have used is setting up a weekly mob programming session.
What is Mob Programming?
Mob programming is not unique to AdHawk, although I only first heard the term this year. Per Wikipedia, “mob programming is a software development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer.”
The following quote from a mob programming proponent further emphasizes the point, which holds for all of us these days (minus the in-person gathering around a projector!):
The basic concept of mob programming is simple: the entire team works as a team together on one task at the time. That is: one team — one (active) keyboard — one screen (projector of course).
— Marcus Hammarberg, Mob programming — Full Team, Full Throttle
Mob Programming at AdHawk
At AdHawk, we are organized into generally teams of 3–6 developers, often with a product manager and other support roles attached. Back in March, seeing the Kodiak team of web developers had a scheduled weekly Friday mob programming session, we took a page from their playbook for our team, the Red Pandas. (Yes, our web development teams all have bear-related names, in case you were wondering!)
Our first session focused on the kind of task that as a remote team we would’ve had likely 50+ slack messages in a team channel about (with a variety of “stuck” moments and context-sharing issues throughout). We wanted to de-duplicate data for our customers that had become messy and a blocker for a feature release and onboarding. Should we do this through a script? What would a rake task look like? Is this spreadsheet the full list of problematic data? All the usual questions that spill out, with the context split among many team members and other colleagues external to the team.
That first Friday in April around noon, fresh into quarantine life and not long after our standup, we gravitated towards this retailer de-duplication task. We looked closely at our Google Sheet of retailer data and split up the manual work identifying how to combine the good and purge the bad, and all cranked through notes on the shared sheet while listening to music. With our Product Manager Taren King there, it was easy to have all the external context for our developers to charge at the task at hand. Within an hour, and after a bit of database cleanup, we were unblocked on a variety of tickets benefiting the whole team and company.
Other Recent Examples of Mob Programming Tasks
So far we’ve had seven sessions across Fridays, roughly 60–90 minutes in length, in looking at my calendar the past few months. We’re finding that often the tasks best suited to these 4–6 person meetings are ones that might sit at the intersection of being quasi-technical and not necessarily the most code-oriented tasks. Think a hybrid of a pairing session and a team or project meeting, with more of a hands-on approach than your typical work discussion.
It might be data cleanup or thinking through large problems (What is causing our lead data to be messy? How can we best match leads to our customers from all sources?). With the insight of every team member’s experiences and respective windows into the code or systems at play, we’re able to make progress quickly in mob programming.
My favorite recent team success story was my engineering teammate Viki Harrod’s project on stores data cleanup, which was a critical issue for us to scale up our B2B product line DealerHQ. We have multiple customer systems across our various product lines and brands, and for our customers to get value out of DHQ, we needed to have a full stores import with clean data in every field in order for leads for our customers to sync all across platforms.
Within our consecutive mob programming sessions, we were able to assist Viki, brainstorm issues with her stores project, and as of last Friday’s session even watch her approach the finish line for our big stores import. This work greatly unblocked our product timelines and tickets.
Thanks to this critical work, our customers will soon have access to powerful reporting and all the features of the DealerHQ product line. They can view their dashboards, listen to store phone calls, call back potential customers, respond to emails, and set up notification emails for their leads. Mob programming was crucial to this large project with many moving parts.
It’s All About Consistency
My biggest takeaway from about a month of mob programming sessions is that this great new habit is a routine with big payoffs. We now have another solid recurring way to encourage team-wide collaboration, particularly during this highly unusual period of quarantines and disruptions to daily life and team workflows.
Seeing the big wins from just our first few sessions and even just having that casual opportunity to hear how everyone’s doing and just hear their voices has made me feel more connected to my team. If anyone has questions or comments about how mob programming has worked or could work for them, please reach out! I highly recommend mob programming any development team’s workflow.
