As many fellow software engineers, I am familiar with several development techniques including XP, pair programming, and TDD. However, I recently came across something new to me in development, a technique named Mob Programming. It immediately picked my curiosity, therefore I decided to read more and share some thoughts after few months of adoption.
Origins
The story begins in 2003, when Moses Hohman called the practice of code refactoring by more than two people Mob Programming [1]. Woody Zuill then brought his experience with this technique to larger audience in conferences and public speeches, defining it as “All the brilliant minds working together on the same thing, at the same time, in the same space, and at the same computer” – we call it Mob Programming” – Woody Zuill [2]
What is Mob Programming?
Well…the name might sound a bit awkward, particularly in the jargon as Mobbing, however it boils down to some good and common value as is
“Unus pro omnibus, omnes pro uno”
well known to cloak and dagger readers and movie passionates as “All for one and one for all, united we stand divided we fall” (Alexandre Dumas,The Three Musketeers)
According to this development technique all teammates work on the same feature or issue, sharing the same IDE in a collaborative way. A sort of pair programming on steroids whereby the entire team has only one keyboard.
Participants to such “feature/issue workshops” are team members but also business experts, advisors, customers or product owners, ultimately all people having a stake on hold and therefore forming an enlarged team, a mob.
The Mobbing approach is not limited to coding. In fact it is often used for purposes such as definition of stories, product design, testing, business and planning.
Roles and Rules
In the mob there is one Driver and many Navigators. Only one person at a time has the Driver role, everyone else has a Navigator role.
The Driver is the only one allowed to use the keyboard, translating Navigators ideas into code. It is recommendable for the Driver to have good coding skills, however experienced Navigators can help and support the Driver as need be.
At times the Driver can be involved in the discussion among Navigators albeit this should happen only sporadically in order to avoid imposing his/her idea.
Navigators are the brains in the workshop. They are required to explore and expose task’s details, devise and discuss options, and eventually explain to the Driver the agreed solution.
Each team member becomes the Driver after a fixed time shift. This ensures everyone’s engagement, shares knowledge, and improve skills.
Here below I list Mobbing rules and advices which obviously can be amended according to everyone’s direct experience using mob programming.
Start with 4-5 teammates. Extend the mob over time depending on your company needs and expectations.
• Swap Driver/Navigator roles every 20 minutes.
• Discussions among Navigators promotes common understanding and knowledge sharing, Driver’s instructions are genuinely code oriented.
• Short and frequent retrospectives, possibly after each session, matched up with concrete action items.
• Agree on logistics such as in person or remote sessions, one or more screens or projector, which IDE, etc…
• no phones, no emails, ideally no interruption.
Final remarks
Benefits of mob programming are manifold and easy to figure out, including (see also Livyson Saymon [4]) teaching and learning from each other, share knowledge, learn by doing, joint decisions, simultaneous decisions and reviews, prevent unnecessary meetings, encourage easy-to-understand code.
There is a good number of blogs and articles about mob programming, how it was adopted for medium to large size projects, and benefits achieved. As it usually happens, pitfalls and drawbacks of a development technique are less popular topics to share.
While a trial adoption of mob programming can prove its expected benefits as well as disclose hurdles and issues, the experience shared by other adopters should motivate companies and teams that explore this technique, crafting own rules.
References
[1] Hohman, M.M. and Slocum, A.C. 2003. Mob Programming and the Transition to XP. EXtreme programming perspectives. Addison-Wesley.
[2] Zuill, W. 2014. Mob Programming – A Whole Team Approach, https://www.agilealliance.org/wpcontent/uploads/2015/12/ExperienceReport.2014.Zuill_.pdf
[3] Lea Kovac Beckman https://blog.prototypr.io/100-of-the-team-in-a-mob-for-12-months-taking-mob-programming-a-couple-of-steps-further-62d1e9962f37
[4] Livyson Saymon https://medium.com/@livyson/using-mob-programming-in-sprint-planning-37506d63a769
