Part 12: Unleash Your Scrum with Multi-Skilled Professionals — Mob Programming to Enable Social Ability
Pair programming showed us earlier how two minds could be better than one. But what if we went even bigger?
Mob programming is a surprisingly effective way to turn your entire team into a problem-solving brain, boosting skills and delivering better solutions faster than ever.
Everyone hates those moments where progress grinds to a halt, waiting for an answer or a specialist to be free. Imagine if those moments never happened. Mob programming is a way to restructure your work so those slowdowns vanish and breakthroughs take their place.
If you’re joining me for the first time, I recommend reading the previous parts for context:
Unleash Your Scrum with Multi-Skilled Professionals — Series Outline
Chapter 10
10.6. Creating Social Ability
Try … Mob Programming
A Short History
Much like a scene from a surgery room, where each individual brings a unique skill to the operation table, mob programming gathers a group of developers around a single task, each contributing from their distinct vantage point.
Although mob programming has gained traction recently, it dates back to early cooperative practices. Moses M. Hohman and Andrew C. Slocum first coined the term in a 2001 paper titled “Mob Programming and the Transition to XP,” which discussed group refactoring.
Around 2007, Woody Zuill and Llewellyn Falco were experimenting with pair programming. Llewellyn suggested transitioning from alternating at the keyboard to adopting the Driver-Navigator (DN) model. In this paradigm, one is the driver who does all the typing, while the other is the navigator explaining the logic and overarching idea behind the code being written. The notion was that for an idea to go from one’s mind into the computer, it must pass through someone else’s hands. This model emphasized role-switching after a specific agreed-upon interval.
A bit later, during a coding dojo session at a code camp, they extended the DN model to groups of four or five people. The setup involved a timer, and every few minutes, the person at the keyboard (Driver) would switch out with someone else in their group, rotating clockwise. Applying the DN model to larger groups showcased the feasibility and benefits of joint coding beyond just a pair. They later tried this approach at future code camps, user groups, and conferences and found the results satisfying.
Around 2010, inspired by the positive experiences at coding dojos, Woody started applying the DN model during team practice sessions while delving into Agile ways of working. They organized code exercises using the DN model with the whole team, rotating the Driver every four minutes. The attendees found the setup enriching as they learned significantly from each other, nurturing a better-functioning programming team.
Subsequently, an opportunity arose to apply this practice in a challenging live project. The team commandeered a conference room to review the project’s state collectively. They began reviewing project documents and code together, and naturally, the DN model took hold. Someone suggested an improvement, handed the keyboard to another person, and navigated the change. They moved from room to room over two weeks, reviewing each day’s progress and opting to continue working “as a team” due to the rapid enhancement in communication, knowledge sharing, and problem-solving they were experiencing. It was around this time they named their approach “Mob Programming.”
Daniel Ståhl and Torvald Mårtensson explored mob programming from an exploratory testing angle in large-scale software projects. They found that bringing together individuals with different backgrounds and competencies to run a single testing scenario collaboratively yielded remarkable value and insights. The shared focus on a single task led to fruitful discussions, rapid troubleshooting, and a sense of joy and enthusiasm in working as a team rather than a mere collection of individuals.
How Does It Work?
Mob Programming is a holistic approach where an entire team dedicates itself to a unified item or feature, sharing a common temporal and spatial environment, all channeled through a single computer. This focus mirrors Pair Programming, where a duo teams up on coding at one computer. Mob Programming extends this principle to envelop the entire team, still orchestrated through one computer for coding and other tasks.
Beyond mere coding, the team collaborates on the entire range of software development tasks, including story definition, design, testing, deployment, and working with customers, business experts, or the Product Owner. This process becomes a series of ongoing workshops where everyone involved, including the customer/product owner, contributes to the software. This rhythm persists throughout the day and each day.
Participation in the mob is an open invitation, not a mandate. Individuals can choose to join the collaborative journey and opt to step away when they wish.
Typically, a mob forms with a group of four or five individuals. The setup is flexible, adapting to whatever resources you have on hand — like a monitor or projector. With a bit of planning, it’s ready to go. Even in virtual settings, the core idea of mob programming works well with video conferencing and screen-sharing tools.
The Driver/Navigator (DN) model is the beating heart of Mob Programming. At its core, one member performs the Driver role, translating thoughts into typed code, while the rest become Navigators — breeding, discussing, diagramming, and disseminating ideas for coding. The Navigators steer the logic and intent of ideas, while the Driver channels these into code. The essence is that for an idea to journey from mind to machine, it sails through another’s hands.
The driver role is rotated briskly, ideally every 4 to 5 minutes, especially in the budding stages of Mobbing. This rhythm ensures everyone frequently savors the Driver’s seat yet keeps the tenure brief to dissuade autonomous operation devoid of Navigator guidance.
Post-session retrospectives are a chance for self-reflection. Simple questions about what worked well and what didn’t, what to keep and what to change, help you develop a Mobbing approach that suits your team’s style.
How Does It Help Multi-Skilling?
Mob programming provides a great environment to learn new skills and broaden your knowledge beyond just coding. The team works together on various software development tasks — defining stories, designing, coding, testing, releasing updates, and working with customers or product experts. Through this teamwork, everyone gradually builds a strong understanding of the entire product development process. It’s a safe learning space where asking questions and sharing knowledge are encouraged, easing the fear of not knowing.
The Driver/Navigator model propels multi-skilling further — for an idea to transition from a mind to a computer, it must traverse another’s hands. Even if the Driver lacks mastery over a particular facet of the task, the collective wisdom of three or four Navigators comes to the fore, guiding the Driver through a learning process. This dynamic promotes knowledge-sharing and on-the-job learning, enriched by continuous discussion, diagramming, and idea-sharing, ensuring that every stride on the project’s path is a step forward in collective skill augmentation.
A Wealth Beyond Skills
Mob Programming elevates software development by encapsulating the virtues of pair programming, such as enhanced solutions, speed, code quality, true teamwork, and 200% accountability. Yet, it unfolds a broader spectrum of transformative benefits.
Here are a few pivotal aspects that set Mob Programming apart:
Eradication of Bottlenecks: The practice advocates a flawless flow, channeling the team’s efforts towards one feature at a time, embodying the one-piece flow paradigm (WIP = 1). This streamlined approach decisively tackles bottlenecks, supercharging the workflow and nullifying queues and excess inventory.
Drastic Reduction in Waiting Waste: Mob Programming enables seamless information transition, eradicating the waiting period for critical information. The ‘question queue time’ — the time spent awaiting answers to pivotal questions — is a prevalent hurdle. When quizzed, audiences at conferences recount waiting times ranging from hours to a week, primarily attributed to challenges in accessing individuals equipped to provide clarifications.
Traditionally, the response to such delays is to pivot to other tasks, albeit at the cost of accumulating ‘inventory’ — tasks initiated but yet to deliver value. While creating a façade of progress, this practice is at odds with delivering value to customers, inadvertently amplifying waste.
A hypothetical scenario where a blocking question arises every hour sheds light on the magnitude of waste contingent on the waiting time. Instantaneous answers curtail waste; a 10-minute wait squanders over an eighth of the day, an hour-long wait consumes half a day, and a day-long wait results in a day’s waste.
Synergistic Interaction Over Summation: A system’s behavior is defined not merely by the sum of its constituents but significantly by their interactions. While working in silos and summing individual contributions yield a specific quantum of work, collaborative endeavors catalyze a considerably more meaningful output, both in quality and quantity.
Effectiveness Over Efficiency and Productivity: The discourse transcends efficiency (utilization) and productivity (task completion), landing on effectiveness — accomplishing meaningful tasks. As Woody Zuill put it, the narrative shifts from “How can we be effective with five people at one computer?” to “How can we be effective if we separate people who should collaborate?” This perspective underscores the pitfalls of specialized silos.
In such siloed setups, the team often works on five separate tasks simultaneously, yet the lack of synergy prevents them from achieving meaningful results. The essence of Mob Programming is not just about completing tasks but delivering meaningful, valuable outcomes.
Venturing into Mob Programming
Identify Targets for Enhancement
Woody Zuill suggests kickstarting the journey with introspection: “What impediments are throttling our effectiveness?” A succinct three-minute brainstorming session can unveil over 50 potential deterrents — elusive requirements, bureaucratic hurdles, context switching, skill deficits, unwarranted meetings, motivation droughts, or prolonged waits for crucial clarifications.
As you immerse in Mob Programming, vigilantly observe the dynamics — how the detrimental factors are being mitigated.
Initiate with Modest Ambitions
Starting your Mobbing journey with non-critical code is wise — it creates a safe place to experiment without the stress of impacting real products. Simple exercises are a great way to begin. While there’s value in eventually working on production code or actual tasks, a relaxed, enjoyable, and welcoming atmosphere — without the pressure of live features — will likely lead to a better learning experience.
Adopt a Gradual, Reflective Rhythm
Starting with modest daily or weekly Mobbing sessions — say, 1–2 hours daily or 2–3 hours weekly — allows for a smooth transition. Gradual incorporation affords the team time to reflect, assimilate experiences, and tailor the approach to their unique dynamics. As familiarity and comfort grow, scaling up the Mobbing hours is a natural progression — a decision best left to the team’s discretion.
Extend an Open Invitation
Initially, the programmers might spearhead the Mobbing initiative. Yet, branching out to a diverse cohort—encompassing testers, product experts, managers, and coaches—can be remarkably enriching. The infusion of diverse perspectives amplifies the collective intelligence, enriching the Mobbing experience.
Ensure a welcoming environment for those hesitant about coding or taking the keyboard. The essence of Mob Programming transcends coding — it’s about fluid ideation, discourse, and validation. Creating an inclusive, participatory atmosphere is quintessential.
Cultivate a Culture of Kindness, Consideration, and Respect
Kindness, consideration, and respect are essential for a successful Mobbing experience. The close teamwork involved demands a friendly, respectful environment to prevent discord and encourage collaboration.
Incorporate Reflective Retrospectives
Post-session retrospectives are a conduit for continuously improving the mobbing experience. A reflective inquiry into what resonated and what requires tweaking paves the way for an evolving Mobbing approach tailored to the team’s unique dynamics.
Seize Spontaneous Opportunities
Sometimes, the spark for Mob Programming might ignite spontaneously. Anton Bevzyuk, introduced earlier in the Pair Work experiment, recounts a tale in which the seeds of Mob Programming were sown unplanned.
On a typical workday, Anton overheard a dialogue between a seasoned developer and a novice grappling with a perplexing issue on their task. Recognizing he had the knowledge to address the problem, Anton volunteered to lend a hand and mooted a trial run of Mob Programming to tackle the issue together.
After a brief rundown of the concept—essentially an expansion of pair programming with an added pair of eyes—the trio was onboard for this exploratory venture.
The transition was surprisingly smooth. When they hit a problem, they realized that a developer from another team had the expertise they needed. They quickly invited the developer to join and, just like that, solved the issue that had been stalling them for half the day. This success showed the power of combining their knowledge and working as a team to solve problems quickly. Excited by how well it worked, they agreed to use this approach again whenever it made sense, appreciating that it helped cut through complex problems without the need for formal setups or long discussions.
Our journey through pair and mob programming has revealed the power of shared knowledge and collaboration to promote a multi-skilled team where knowledge flows freely, and everyone learns from each other’s experience. Swarming, which we’ll explore next, unlocks another level of “Social Ability” within your team, giving you the tools to tackle any challenge with speed and creativity, from urgent bug fixes to breaking down complex new features.
Continue exploring the nuances of multi-skilling in transforming our Scrum practices and elevating our teams to new heights of agility in the next part of the series:
References
- Cesário Oliveira Ramos, Ilia Pavlichenko. Creating Agile Organizations. A Systemic Approach (Addison-Wesley, 2023)
- Joseph Grenny, Kerry Patterson, David Maxfield, Ron McMillan, Al Switzler. Influencer. The New Science of Leading Change (McGraw Hill Education, 2013)
- Daniel Ståhl, Torvald Mårtensson. Mob programming: From avant-garde experimentation to established practice (Journal of Systems and Software, 2021)
- Falco L. Llewellyn’s strong-style pairing (2014)
- RooksbyJ. et al. The theory and practice of randori coding dojos (2014)
- Bach J. Exploratory testing explained (2003)
- Hendrickson E. Explore It!: Reduce Risk and Increase Confidence with Exploratory Testing (Pragmatic Bookshelf, 2013)
- Mårtensson T. et al. Exploratory testing of large-scale systems — testing in the continuous integration and delivery pipeline (2017)
- Woody Zuill, Kevin Meadows. Mob Programming. A Whole Team Approach (LeanPub, 2016)
- Woody Zuill. Mob Programming and the Power of Flow (GOTO, 2019)
