Mob Programming: An Organizational Tool
Updated: Apr 26
In a truly agile team, you must constantly ask yourself, “How can we be better?” Nobody is perfect, so we must understand that we, implicitly, can never be perfect ourselves. My team of seven developers asks ourselves this question weekly. As you probably know, all developers are inherently opinionated. There is always a way to improve, but it can be difficult to agree upon which direction will guide us to the promised land of almost-perfect. We are self-aware wolves and context matters; something that worked in one team may not have the same effects in other teams.
Where does this lead us? Experimentation. Experimenting is one of my team’s core values, and it has led us to both succeed in ways we never saw possible and fail quickly in others. One of our current experiments involves answering the question, “How do we share the breadth and depth of knowledge that some of our core members have with the other members?” After lengthy discussions, we turned to “Mob Programming,” which was previously used by one of our developers who had a great experience.
For the past two months, we have experimented with how Mob Programming works within our team. The scope of this experiment was confined to half of the team working within and half of the team working outside of the boundaries of the experiment. Given the size of our team, we deliberately chose to use four of our developers within the mob at a time.
If you are reading this, I would assume you are familiar with the underlying concepts of Mob Programming, and if you are not, I would highly encourage you to check out some of these resources provided to me by @mob__mentality and @tottinge:
What is Mob Programming?
What are some of the claims of mobbing?
How do you have a healthy attitude while mobbing?
An incredible breakdown of many different patterns can be found here:
After some initial experimentation, we agreed that four members was an appropriate mob size. This was also derived from the past experience of one of our developers. Having four members enabled us to split roles into two mobbers, who were able to strategize the next steps, while the driver listened to the navigator’s current direction. These three distinct roles split between four people was paramount to our success; note that these roles can differ from team to team. Context matters, and you should do what your team requires to be successful.
Given our core value of experimentation, we allow each mobber ample time to experiment, collect their own results, and analyze the results, then come together to discuss each person’s experience. Our mob structure consisted of two members who were always within our experimental mob so they could share their experiences with the rotation, and guide the experience as the other two members of the mob were rotating on a project-to-project basis.
Rotating through the mob proved to be beneficial for our team due to the break it gave team members who were not used to either being extremely social throughout the day or explaining and detailing every high-level action we made while developing. These two pieces are the largest differences between traditional programming and Mob Programming. In each project, we typically had two or three of our developers with a high-level understanding on the project details at one time, and we had one to two developers who required knowledge to be shared with them. The lack of domain knowledge is largely due to the rapid expansion of our team, but we are at the point where it is important for us to accelerate the domain knowledge transfer amongst ourselves. This should provide the underlying scope of our experiment, and you can judge the efficacy of our experiment in relation to your work environment.
I initially had reservations around this experiment, and I believe it best to be honest with you so you can understand how my view has changed, and how my view has remained the same. I come from a mixture of business and development experience, and I stand somewhere in the middle of finding what’s best for the business versus what’s best for the development team. There is give and take on both sides, so it’s just a matter of fleshing out the details so we can make the best call for every independent context (remember, context matters).
What were some of my reservations?
How can four people working on the same story within a project be as effective as four individual people working on different stories within the same project?
How do you prevent “Herd Mentality” from rising and following the “catchy” things as commonly defined in social psychology?
Overhead will always exist. I believed the overhead of synchronous development of four members may not be worth the overhead of asynchronous development from four members actions.
What were some of my perceived benefits?
Transfer of knowledge will increase due to people collaborating within areas where some team members are experienced and others are inexperienced.
Onboarding a new member of the team will be much easier if three others are assisting in reducing the learning curve.
I believed we would have a higher alignment among our team.
As with every experiment in life, there will always be edge cases, or areas where the experiment could have been optimized. To continue building the picture, we only used Mob Programming for larger projects. Bug squashing and tiny feature development was left to the independent and pairing team that was left out of our mob. As a brief look-ahead to my summary, I believe that Mob Programming can be an incredibly powerful tool for our team to utilize, but I do not believe Mob Programming should be used 100% of the time. Why is this the case?
There are remarkable benefits to utilizing Mob Programming, which are listed below:
Transfer of knowledge
Quality of code
Onboarding a new member of the team
Discussing large architectural decisions
Reduces overhead of context switching
These benefits can be very powerful when used correctly, just as pairing with other developers can be powerful when used correctly. Specifically, I believe that the best way to bring new employees up to speed within a rapidly growing team is through Mob Programming. We used our most recent hire exclusively in our Mob. With this experiment alone, I have seen this developer pick up more concepts very quickly. Two other hires were brought in at the beginning of November, and they have had a remarkable impact throughout our codebase through the rapid transfer of knowledge that occurs within Mob Programming.
Knowledge Transfer occurs in many different ways throughout Mob Programming, I want to dive further into various types. The transfer of knowledge I witnessed included domain knowledge, debugging techniques, tools used for easier development, developer habits, and more. This has been extremely advantageous to our team, as we have two individuals who have not previously worked in a team setting. Please do not confuse this with being a junior developer, as they are both very experienced with independent development. However, a Mob Programming team organization has been extremely powerful in sharing the habits, domain knowledge, and other knowledge described above. They have seen a rapid increase in all of these skill-sets, and I am incredibly pleased with this result. Furthermore, there are other noteworthy benefits to utilizing Mob Programming for team organization. An increase in team chemistry, increase in quality of code, and an increase in architectural discussions are all examples of the benefits we saw throughout our experiment.
All of these benefits sound like a no-brainer, so why would I believe that we couldn’t do this all of the time? As with everything in life, there are pros and cons. I want to dive into my reservations, to express why I believe Mob Programming should not be used at all times. First, I saw the immediate social psychology patterns that are true within large groups of individuals, specifically, “Herd Mentality”. In our first couple of weeks, it was quite clear that the team was bifurcated between those of us currently working “in” the mob, and those of us working “outside” of the mob. This was massively difficult as some of the decisions being made on either side were not well-communicated throughout the entire team. The purpose of our mob was to be synchronous and adding distractions such as pulling in other members or providing meaningful and well-thought-out feedback to stories outside of the mob’s scope could be an anti-pattern to the context of our experiment.
This, in turn, has brought me to my next reservation, which is that having four full-time developers spending their time on one piece can be extremely expensive for the company. It is important to maintain the perspective of the company to determine which piece of our work provides the most value at any given time. In my opinion, I do not believe the value seen in our experiment will transfer completely to our development life-cycle on all projects. At times, it will be more valuable to the company to have four developers working in tandem. Increases in the balance of our domain knowledge throughout the team and bringing developers up to speed with current technologies are extremely valuable to the company. But, these values will diminish over time, as each developer begins to reach the level of knowledge of other developers within the team. Once the value of our knowledge transfer diminishes, I believe that previous team structures will continue to provide high value for the company.
Finally, I disagree with the idea that overhead is reduced through Mob Programming. Overhead is neither created nor destroyed, it is simply placed in different areas to enable a team to act better in different contexts. The overhead of context switching is drastically reduced in Mob Programming, but given the synchronous characteristic of Mob Programming, equal overhead is added between projects and/or stories.
This all stems from my team’s desire to continually improve through the use of experimentation, and I believe we will continue growing both as a team and as individuals. As stated previously in this article, I find it important to understand that context matters. The experiment used with the scope provided in this article may provide different results for your team, and I encourage any and all feedback. In summary, I think there are plenty of reasons to utilize Mob Programming as a tool. The benefits witnessed throughout the Mob Programming organizational architecture is clear in some cases, but I do not believe it should be used in every case.