About this Publication
In this report we explore a set of mob programming patterns discovered by two different teams — LendingHome and IBM — after more than a year of practice. Patterns we found include emergent roles in the mob such as the recorder, researcher, and facilitator, collaboration patterns such as create a punch list and form splinter groups, and driving patterns such as think out loud and asking the mob to tell me what to write. While the patterns themselves proved interesting and useful, we were surprised at how much our mob programming improved after even modest reflection regarding our practice. In addition to the mob programming patterns, some of which corroborate experiences shared by other teams, we discuss the benefits of pattern harvesting as a mechanism for supporting reflective practice and general process improvement.
1. INTRODUCTION
When we first heard about mob programming it sounded preposterous but also intuitive, radical but familiar. Like many teams who have tried mob programming, we were intrigued by the stories we’d heard. We were also searching for fresh ideas that might help us relieve nagging problems. How do we spread knowledge amongst teammates? How can we complete reviews faster and improve flow? How can we amplify fun and keep quality up even during stressful times? After some practice, mob programming helped us improve in these areas and more, but it took time and practice to become an effective mob. Our greatest improvements began when we started paying attention to emergent patterns of interaction among individuals in the mob. What follows is a sample of lessons from our experiences presented as a collection of patterns for mob programming.
1.1 About Mob Programming
Mob programming is an approach to creating software in which the whole team works together on the same thing at the same time [Zui14]. Woody Zuil’s experience report introduced mob programming to the world and shared a set of patterns and practices his team used to work collaboratively as a single group, a mob. The core patterns include sharing a single keyboard and computer, swapping every 15 minutes, and promoting respect in personal interactions across the team [Zui14]. Since then, other teams have shared their experiences with mob etiquette [Ker15], scaling the practice [Luc17] , remote mobbing [Fre18], and measuring productivity [Ham18], as well as swarming patterns and benefits [Ars16].
Thinking about the lessons from these experience reports and reflecting on our own practice we have come to believe that, at the heart of every effective mob there is a group of people working from a place of mutual respect to deliver the best software they can, as fast as they can. Effectiveness of a mob is ultimately determined not by the tools a team uses but by how well teammates communicate with one another.
1.2 Discovering Patterns
A pattern is a repeatable solution that emerges in response to a specific problem in a particular context. Christopher Alexander is often credited with popularizing the idea that patterns should be cataloged so others may reuse and learn from them. His book, A Pattern Language: Towns, buildings, construction, outlined 253 common forms for organizing regions, cities, neighborhoods, and buildings [Ale77]. His book set the tone for pattern catalogs that followed. Eric Gamma and friends introduced one of the first sets of design patterns to the software world with their book, Design Patterns: Elements of Reusable Object-Oriented Software [Gam94]. Patterns codify knowledge into a reusable package that is easy to share with others thus creating a language everyone may use to describe ways of working, solutions, and even problems themselves.
Our teams are generally quite comfortable with patterns. We apply patterns while programming and designing architectures. We look for patterns in our code so we can extract and share them with teammates. We even record design decisions using Architecture Decision Records (ADRs), which roughly follow the form of a pattern [Kee18]. It seemed natural for us to use the same principles that we use to design software systems to also design our software development methods.
Our mob programming patterns started as basic observations about how our teams worked. After a few mobbing sessions we noticed consistent working and communication styles emerging. One night over beers while talking shop and swapping stories about our new teams, it quickly became obvious there was significant overlap in how our different teams mobbed. We also noticed some interesting differences. As one idea led to another, we decided to try our hand at formulating our observations as structured patterns.
For each potential pattern, we try to articulate three basic parts. The context describes the situation in which a pattern takes place and the general problem the team faced. In response to this problem, we apply a solution that works within the constraints of the context. As a result of applying the solution, there are consequences, both positive and negative, which describe a new context that is a direct result of the solution.
As we recorded the patterns that we discovered, our mobbing began to evolve. Instead of instinctually reacting to a situation, we started to intentionally choose how to direct our mobs. Reflecting on the way we work and codifying our observations as patterns helped us become better at mob programming.
1.3 About the teams
We’ve been practicing mob programming off and on for over one year. In that time, we’ve mobbed with three different teams in both an “on demand” context as well as full time. While we were both new to mob programming, we already had positive experiences with pair programming, test-driven development, and several other technical practices that can trace their roots to Extreme Programming (XP) and its sibling Agile methods. Michael has been developing software for over 15 years while Joe has worked in the field for just over three years.
We timidly dipped our toes into the mob programming waters with “Mob Mondays” in early 2018. Our team at IBM was co-located and mobbed intermittently through the fall of 2018, when Michael left IBM and the team. Shortly after Michael’s departure, Joe also joined a new team within IBM. Both of us felt mob programming was interesting and had many positive benefits that we wanted to explore with our new teams.
After leaving IBM, Michael joined LendingHome, a four-year-old FinTech start-up with offices in San Francisco, CA and Pittsburgh, PA. LendingHome is the leader in bridge-style mortgage loans. The LendingHome Pittsburgh team was responsible for maintaining and extending a large Ruby on Rails application. While the nine person team was experienced, with an average of over seven years in the software industry, Michael’s new teammates were new to LendingHome and the mortgage domain. As a result, the team often lacked the context, in either the system or domain, needed to complete work. The LendingHome Pittsburgh team meets as a mob as needed, up to several times each week to work on backlog items together.
Meanwhile, Joe joined the new IBM Document Ranker Team as team lead. This new team’s first mission was to port legacy machine learning systems to newer frameworks supported by the Watson platform. This involved a healthy mix of development and operations work, which was a change for most of the team. The team was relatively fresh, with an average of three years of professional experience. They were also split geographically between Austin, Pittsburgh, Yorktown, and Raleigh. The IBM Document Ranker team immediately began mobbing full-time as a way to get to know each other and learn the codebase. Mob programming stuck, and the team continues to mob daily on one backlog item at a time.
In the following sections we will share the patterns we discovered across both the LendingHome Pittsburgh and IBM Document Ranker teams. For this report we chose to focus on patterns that seemed to happen frequently, patterns that we haven’t been documented elsewhere, and patterns that come with an interesting story. The pattern names in the following sections are highlighted in underlined italics. We’ve organized the patterns around three categories: mobbing roles, collaboration patterns, and driving patterns, as summarized in the pattern map shown in Figure 1.
Figure 1: Pattern map summarizing the teams’ mob programming patterns Background
2. MOBBING ROLES
In nearly every mobbing session across both teams we noticed individuals fill specific roles within the mob. Some of these roles helped the mob move forward more smoothly. Others emerged in response to a specific need. What we found most interesting was that there are more roles operating within a mob than only the driver and navigator. Individuals in the mob seem to cooperatively self-organize to fill specific and necessary niches required for the mob to work effectively. We’ve categorized this set of patterns as mobbing roles. In addition to the facilitator and recorder documented in this section, we propose there are other roles such as the researcher and devil’s advocate, not described fully in this report.
2.1 Pattern: Facilitator
In our experience, mob programming is not a natural process for many developers. Both of our teams enthusiastically participate, but none of us really knew how to mob in the beginning. Some developers in the mob were experienced pair programmers while others had done very little collaborative coding. This mixed bag of experience, combined with competing priorities, varied working styles, and the typical banter that seems to accompany any group of software developers in an enclosed space, creates fertile ground for disruptive behaviors.
All of the cited experience reports on mob programming emphasize the importance of mutual respect among members of the mob. As some teams have reported, experienced mobs can self-regulate easily when the environment and context are right. In our experience, this ideal is a learned behavior. While respect is a prerequisite for mobbing, sometimes a gentle prod for the group to focus, move forward, or pipe down is just what is needed. In most of our mobbing sessions, a facilitator has emerged from the group to steer the mob and encourage participation from everyone.
We have never assigned a facilitator ahead of time and it was never an explicit role in the group. Someone within the group has always emerged to keep the mob on task, prevent distractions from derailing the group, and encouraging participation. Anyone on the team might act as a facilitator and the person serving as the facilitator can and will change throughout a mobbing session. We’ve also seen facilitators encourage the mob to split into splinter groups when the work at hand no longer made sense in the context of the current mob. Occasionally we’ve seen emergent facilitators halt work entirely when the requirements were not clear or when the mob’s collective energy suggested that everyone needs a break.
On our teams, especially in the first several weeks after introducing mob programming, we often filled the role of the facilitator. We think this is because we had some prior experience with mob programming and were passionate about the practice. We also experienced first hand situations in which the mob meandered for hours refactoring, adding tests, and performance tuning, only to realize that they achieved little progress towards finishing the day’s tasks. As champions for the practice, we had a stake in making sure the mob was successful.
2.2 Pattern: Recorder
When a mob is running smoothly, we noticed there can be many things happening simultaneously. The driver writes code in collaboration with the navigators. Researchers emerge to find answers to open questions and run down details needed for the code to move forward. As design decisions are made and details are discussed, someone on the team takes notes for the group. We call this person a recorder.
Like the facilitator, recorders emerge in response to the current conditions in the mob and anyone in the mob can take the role. We should note that it’s rare for a person to wear multiple hats at the same time and roles change frequently. Recorders volunteer to capture design decisions and other technical details for the team and there might be multiple recorders at work at any given moment. On both the LendingHome and IBM Doc Ranker teams, recorders take notes in a shared document, such as a Google Doc or Box Note, that they immediately share with the mob.
Recorders capture information on a variety of topics. They get a headstart on writing new Architecture Decision Records (ADRs) [Kee18]. They think through and create test or deployment plans for future use. They gather resources discussed during the mob such as blog posts and API references. Sometimes recorders capture step-by-step instructions for how the driver is performing a specific task, building team documentation in real-time.
The documents a recorder creates make the artifacts created by the mob more whole, more complete. We typically see recorders emerge when there are more than three people in the mob and most often during design discussions. Not having a recorder hasn’t harmed forward progress. Perhaps the greatest positive impact recorders have on the team is that their notes make it easier to update documentation later. Occasionally the team will need to backtrack a design, in which case these notes become essential. We’ve even seen times when the recorder completes the documentation work during the mobb session, getting the work item that much closer to “done done.”
3. COLLABORATION PATTERNS
Working together as an effective mob takes practice. While trading stories we learned that each team has uncovered different ways of working together. Most of the practices we discovered focus on organizing work and improving participation. We think these patterns emerged in response to an innate desire everyone has to ensure the mob is productive and efficient. Many teammates feel at least some anxiety that mob programming might be perceived negatively by managers and co-workers unfamiliar with the practice and so want to put the best foot forward as possible. We’ve categorized these ways of working as collaboration patterns. In this section we describe the punch list, ridin’ shotgun (which we propose as an anti-pattern), and mute the mic patterns. There are a few additional patterns we’ve experienced that we think are interesting but are not described in this report including forced swap, splinter group, forced break, distracted non-participant, and fight club (definitely an anti-pattern).
3.1 Pattern: Punch List
Across both teams we’ve seen situations where members of the mob invent different approaches for tackling a problem. It’s easy for people to come up with new solutions or focus on different aspects of a problem such that picking an approach is challenging. There is always something to fix and a different way to solve a problem.
When competing ideas for what to work on next begin to pile up, we record them in a punch list to work on later. Some ideas we address during the same session. Others we record as backlog items for another day. Some ideas we never get around to doing (and that’s OK too). We try not to judge the merit or priority of an idea in the moment. Instead we leave the priority open for the mob to decide when it’s time to start a new thread of work.
Figure 2: A punch picture drawn by the IBM Doc Ranker team on a remote whiteboarding app that captures the changes required in multiple codebases to complete a backlog item.
We’ve noticed that recording ideas in a punch list helps keep the mob on track by creating concrete goals. Creating a running punch list also ensures everybody feels like their voice is heard. There are still sometimes disagreements when picking an item from the punch list, but such disagreements can be solved by creating a temporary splinter group (in which one or a few people break away from the mob to tackle a particular problem) or by letting an emergent facilitator arbitrate the decision.
Both of our teams practice some version of the punch list. In addition to punch lists, the Doc Ranker team uses a graphical form of task list they draw on a whiteboard that they call a punch picture, an example of which is shown in Figure 1. In the punch picture, tasks are overlaid onto an architecture sketch so the whole team better understands sequence and components involved in the work to be done.
3.2 Anti-Pattern: Ridin’ Shotgun (a/k/a Dominate the Mob, Boosting your Mic)
To “ride shotgun” means to sit in the front passenger seat of the car, next to the driver. The term originates from the American Old West when the person sitting next to the stagecoach driver literally held a shotgun to protect the wagon from bandits. In modern times, a person riding shotgun has an inordinate amount of control over the car’s environment. They are uniquely positioned to adjust everything from the radio to the temperature controls. Often this person is also given sole navigation duties.
During some of our mobbing sessions we’ve noticed that sometimes one person just talks too darn much. When a member of the mob assumes sole command over the group’s direction, they are ridin’ shotgun. We’ve also sometimes called this pattern dominate the mob.
When someone is passionate and knowledgeable about a topic, it can be easy for them to dominate a group conversation. This seems to be especially true when the rest of the mob is less knowledgeable or might simply be trying to get a task completed. We think that ridin’ shotgun can help the group move forward in the short term but has an overall negative effect on the mob by preventing gelling, thus we consider it to be anti-pattern. Allowing one person to solely direct the mob for too long discourages others from active participation, including the driver. As a result teammates ask fewer questions and we lose out on some of the ancillary benefits of mobbing.
In some mobs we’ve seen the person who emerges as a facilitator fall into this anti-pattern. When this happens, there are a few ways we’ve course corrected, not all of them good. The best situation is when someone recognizes the situation and helps the person ridin’ shotgun give others a chance (mute your mic pattern). In the worst case we’ve seen, one navigator attempted to wrest control from the person ridin’ shotgun, forgetting all tenants about mutual respect and consideration. The result was an argument with no winners that we’ve dubbed the fight club pattern.
3.3 Pattern: Mute your Mic (a/k/a Choose not to Dominate, Take a Back Seat)
The Doc Ranker team is almost fully distributed. One day the mob had a particularly difficult start to the session. To keep things moving forward, Joe, much to his chagrin, did most of the talking while the group remained silent. In an act of desperation to jump start participation, Joe muted his mic, leaned back in his chair, and waited to see what happened. After what felt like an eternity, someone else in the mob broke the silence by suggesting an idea to move the team forward. With the ice broken, more navigators chimed in and the mob became fully engaged.
We’ve seen mobs remain mum for many reasons. Sometimes people become distracted non-participants and focus on other work tangential to the mob’s current mission. Sometimes teammates didn’t feel comfortable raising their opinions in a fast paced discussion. We’ve also seen situations when someone is already ridin’ shotgun and nobody else feels compelled to contribute. The general expectation in our mobs is that everyone contributes in some way to help the group. Some people—be it their personality or the temperament of the mob—find themselves contributing disproportionately compared to others.
One technique we use to encourage participation is to force it by asking individuals who are sharing more than others to mute your mic for a few minutes. As Joe’s story shows, an awkward silence can be a great way to kick start collaboration.
When we take a back seat, we sometimes shift into a different role to keep our minds busy and give the mob, and ourselves, a chance to recalibrate. Instead of jabbering on and dominating the mob at the expense of collaboration, we may slide into a new mob role such as a recorder or researcher. We can also help the mob by contributing to the running punch list. In any case, after a few minutes out of the mix, we can participate as a navigator on a more equal footing with our team.
4. DRIVING PATTERNS
As originally presented by Woody Zuil, the mob’s knowledge flows through the driver’s fingers as they “merely” follow others’ instructions. While this approach to writing software can work well, in practice we’ve noticed that the person at the keyboard often has more influence over the mob than a mere typist. We want the navigators to decide the direction of the mob since navigators embody the mob’s collective wisdom. In spite of this, in our experience the current driver seems to determine a mob’s overall effectiveness.
Given the driver’s outsized influence over the mob, we decided to share the different ways our drivers work as driving patterns. In addition to the two patterns we document in this section, plowing through and tell me what to write, there are other driving patterns we identified but didn’t have the space to share including thinking out loud and driving on autopilot.
4.1 Pattern: Plowing Through
One situation we’ve seen arise multiple times across both our teams is for the driver to be extremely knowledgeable or opinionated about the task at hand and then silently go about the work while the rest of the mob watches. This situation seems to happen most often when the mob is inexperienced, the driver is passionate about a particular chunk of code, or the current driver is anxious to accelerate the group’s progress.
When a driver silently decides how to change the code while the mob quietly watches, we say the driver is plowing through the work item. One downside we’ve seen to allowing the driver to plow through a work item is that it decreases overall engagement. Are people in the mob silent because they agree with what’s being done, don’t understand, or aren’t paying attention? In the worst case we’ve experienced people simply writing code on a shared screen while in the same proximity of teammates, negating the whole point of mobbing in the first place! Sometimes an emergent facilitator chimes in to help correct course. Other times the driver notices what’s happening and self-corrects their behavior.
On the whole we think plowing through has a strong negative effect on the mob, but there are times when this pattern is useful. One example we’ve seen is when a work item is under a strict deadline and simply has to get done. Even so, we think it’s possible to create a more positive experience, especially for new teammates, when the driver shares their plans while working to complete the task (think out loud) instead of going silent.
4.2 Pattern: Tell me What to Write
Sometimes when we assemble as a mob, only one or two people have the necessary context about our goal to kick things off. This can happen for a few reasons. For example, a new teammate doesn’t yet know the tech stack, or an old teammate was one of the last programmers standing on a project. More often, only one or two people from the current mob explored requirements ahead of time and have the background needed to start a work item. Presented with this situation, drivers have little choice but to seek help by asking the mob, tell me what to write. Asking for help from the mob can start with simple questions. Things like “What section of the code is that in?” “What class is responsible for that?” “How do we go about testing this?” Occasionally a driver will outright give the command, “Tell me what to write!”
In our experience, seeking help from the mob in this way can be quite thrilling. Engaging the mob is a great way to encourage participation. It can be a fun, “I don’t really know where we’re going but I’ll learn while we go there!” experience. Telling the driver what to write can also be frustrating for portions of the mob and we’ve seen this practice create opportunities for distracted non-participants. Occasionally we’ve seen drivers hanging on for dear life as they try desperately to implement what the mob excitedly explains. When this happens, it can be a clue that we are not working at the highest granularity of abstraction that everyone understands. We’ve found this is a good time to pause and talk, lest the current driver becomes even more lost and starts feeling like a glorified stenographer. In spite of these slight negatives, overall we think this is a terrific pattern and we generally encourage it in our mobs.
Table 1: Summary of all patterns harvested by the LendingHome and IBM teams.
5. CONCLUSION
In “Mob Programming: a Whole Team Approach,” Woody Zuil presented one way of practicing mob programming that was born from three years of experimentation. That experience report outlines a basic framework for good mobbing practice, but as we’ve learned over the past year or so, there is still much we can all learn about mob programming. We’ve also learned that there are many different paths that lead to success. There is no one way to “do mob programming.” While there is no one best way, there are many practices that seem to work well. The applicability of any particular practice is highly dependent on the context. There seem to be many practices that work most of the time. There are also some, such as the plowing through pattern, which are negative in most contexts but can sometimes be useful. Context rules the day! In our experience, patterns are a fantastic vehicle for describing how we work in context.
Codifying the way we work as patterns has proved to be a powerful tool for honing our practice. The mere act of teasing out the patterns seems to make the group more introspective and intentional about what we do and how we do it. Instead of instinctually guessing what to do next, we instead pull the most appropriate pattern for the present context from our catalog of patterns. Even better, patterns are easy to capture and share, so we can take advantage of what other teams are learning too. In the hope that we might jump start our collective intelligence about mob programming and make it easier for other teams to build on what we’ve learned, we have started a GitHub repository to collect mob programming patterns (https://github.com/michaelkeeling/mob-programming-patterns). We seeded the catalog with our set of patterns. We invite you to join us by adding new patterns (and anti-patterns), trying out patterns with your teams, and by sharing your experiences with mob programming. We encourage you to build on our patterns. Try them out for yourself. Maybe avoid the anti-patterns we uncovered. Share your stories and mob on.
6. ACKNOWLEDGEMENTS
Thank you to all of our teammates for being willing to give mob programming a try. Huge shout out to our shepherd, Rebecca Wirfs-Brock. We’ve consistently challenged experience report style norms and we are extremely appreciative for Rebecca’s support and guidance as we experiment. We also would like to thank all the fine craft brewers whose tasty beverages provided at least part of the foundation upon which our pattern discoveries were built.
REFERENCES
[Ale77] Alexander, Christopher. A Pattern Language: Towns, buildings, construction, Oxford University Press. 1977
[Ars16] Arsenovski, Danijel. “Swarm: Beyond pair, beyond Scrum,” Proceedings from Agile2016, August 2016, https://www.agilealliance.org/resources/experience-reports/swarm-beyond-pair-beyond-scrum/, retrieved May 24, 2019.
[Fre18] Freudenberg, Sal and Wynne, Matt. “The Surprisingly Inclusive Benefits of Mob Programming,” Proceedings from XP 2018, May 2018, https://www.agilealliance.org/resources/experience-reports/the-surprisingly-inclusive-benefits-of-mob-programming/, retrieved May 24, 2019.
[Gam94] Gamma, Eric; Helm, Richard; Johnson, Ralph; Vlissides, John . Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley Professional. 1994
[Ham18] Hamid,Amr Noaman Abdel. “Experimenting with Mob-Programming,” Proceedings from Agile2018, August 2018, https://www.agilealliance.org/resources/experience-reports/experimenting-with-mob-programming/, retrieved May 24, 2019.
[Kee18] Keeling, Michael and Runde, Joe. “Share the Load: Distributing Design Authority with Lightweight Decision Records,” Proceedings from Agile2018, August 2018, https://www.agilealliance.org/resources/experience-reports/distribute-design-authority-with-architecture-decision-records/ retrieved May 24, 2019.
[Ker15] Kerney, Jason. “Mob Programming — My First Team,” Proceedings from Agile2015, August 2015, https://www.agilealliance.org/resources/experience-reports/mob-programming-my-first-team/, retrieved May 24, 2019.
[Luc17] Lucian, Chris. “Growing the Mob”, Proceedings from Agile2017, August 2017, https://www.agilealliance.org/resources/experience-reports/growing-the-mob/ retrieved May 24, 2019.
[Zui14] Zuil, Woody. “Mob Programming — a Whole Team Approach,” Proceedings from Agile2014, August 2014, https://www.agilealliance.org/resources/experience-reports/mob-programming-agile2014/ retrieved May 24, 2019.
