Chris Lucian

I want to start out by saying that much of this will be related to anecdotal evidence unless I call out to another resource. If you are skeptical, my goal with this post is to bring you to the point where you can see how it can possibly be more financially responsible to Mob over Solo Development.

Each one of these topics could be their own post. This is more of an outline to a narrative rather than a complete description of each. Please research!

Time to start with the most common question I have received. How could you possibly produce more with 4 people working on one thing over 4 people working on 4 things?

The answer to this question is the aggregate of each of the following sections. Mobs in my experience have higher quality, lower technical debt, better flow efficiency, higher quality feedback loops, better utilization of physical space, fewer meetings and ceremony, high psychological safety and higher quality decisions on roles needed in the team.

Ultimately people on the mobs learn from each-other faster and discovery new ways of working smarter more often. The team then creates better abstractions and does more with fewer lines of code. 

As a side note, since Mobbing feels so expensive I believe people in general are more likely to look for flow efficiencies on a team. For example we have encountered multiple developers where the mob has automated 80% of what the developer did every day. We have essentially recovered entire full time employees from their repetitive tasks that were not obvious when working solo.

In the past I have worked for companies that were ok with some learning on the job, but usually I was assigned tasks people trusted me with and I had to go learn on my own. In fact I realized at some point that the opportunities I had were directly tied to the learning I did outside of the office instead of on the job. Everyone in a Mob now has the opportunity to learn from each other, rather than be at the mercy of the person they report to. If there is a large variety of skill levels in a single mob, the more experienced people learn about coaching, and the least experienced people get leveled up technically very quickly. One of my favorite stories I have from our visitors is when Jason Weimann commented on a group of developers "Wow that mob is really are writing clean code, refactoring their code, and test driving all their code. How long have they been doing this?" our response was "Oh those are the interns!".

As a solo developer there are only so many experiments you can commit to without buy in from the entire team. When working with teams that seemed to be afraid of change, people would have an idea that would immediately get shot down and we would go back to the old way of doing things. I look back now and I feel like that reaction was based in fear. The amount of time people would need to spend learning those new technologies is daunting and would likely require significant extra effort. Also if recognition is based on individual performance everyone would be motivated financially away from incorporating change into the development stack.

In a mob however we end up in an entirely different scenario. One person can navigate their idea in-front of the mob. If the team does not like it they refine it together rather than cut it out outright. This has quickly lead us to capabilities like TDD, BDD, CI/CD, Database Continuous delivery, and infrastructure as code. Over the last 8 years the time saved by the team by incorporating those technologies is on the order of weeks to months per feature. Each time we take on something new we also take on a more ambitious project with new capabilities and learning needs.

We have likely all been through that mad dash to download someone's brain in 2 weeks before they leave a company. That mega silo that has been working on the project happily for 10 years then moved on to something new. They give their two weeks notice, management waits two days to tell the team. Then all hell breaks loose as we pretend we can learn everything they knew about the project from their perfect documentation. We then spend hundreds of hours reading said documentation to make changes to a scary complex system. Ok being a little dramatic.

Mobs do have the luxury of having that information readily available to members of the team. This does not mean we wont end up with silos but it becomes much harder to create one. This also means that some sort of chaos engineering for the team is also possibly a good idea. For example requiring every team member spend only 2 years time in the last 3 years of development on any one project. Forcing that "hand off" of information to happen on a regular basis. This allows the team to think about how they would get better at this knowledge transfer without the heavy risk of turnover at the company.

I really like this graphic from Llewellyn Falco which quickly depicts the benefits of working as a team on code, especially from a quality standpoint. If everyone can contribute at their collective best as a team of 4 the resulting quality comes out to be quite different from a solo developer or even a pair.

I like to tell people that mobs have a collective willpower. If you treat willpower like a muscle we can lift more together as a group. This means we stop eating the comfort food and start eating healthy because we have an accountability circle with us all the time.

Practices like TDD using Red Green Refactor requires a lot of discipline to refactor while green, or refactor at all. Mobbers help each other keep an eye on when things are going south and reminding the team to do the right thing. It is easy to say "let's skip this test" or "we can refactor after we deploy" when you are by yourself. Not when you have 3 other people with you.

Lean software development teaches us to favor flow efficiency over resource efficiency. In the example of mob programming looking at a team with 4 specialists, front end developer, back end developer, tester, and database admin. In a traditional solo developer environment, the team might be accepting tasks separately creating a value stream map with a significant amount of non value added activities like hand offs and documentation.

In a mob containing these 4 roles we experience something entirely different, we reduce resource efficiency to increase flow efficiency. This results in a lower amount of waste in the system. Vertical slices get to customers faster leading to better decision making by the organization through faster market validation. If you want to achieve daily releases to production, organize your team in such a way that hand off times and waste related to deployment is at a minimum. This creates faster and more consistent opportunities for pivots which will lead to more consistent financial growth.

Comparing working in a mob today to working solo years ago I realize that not only my own capability but the capability of my team had been stifled. Consider someone working on a team who reports to a manager or a lead developer. How often do they get feedback from others that is presented in a way to help develop their skills. In my experience the only time I heard actionable feedback was when we did a deploy or during an annual review. At most I received 2 instances of actionable feedback a year in the office. I was able to get additional feedback from user groups, so up to 12 more times in a year. 

In a mob however, through retrospectives and eventually impromptu reflections we created an extremely high frequency feedback loop. This resulted in all the little inefficiencies plaguing us to gradually disappear over time. Even topics that would not normally be noticeable to solo developers came up as areas for improvement. The opportunities for receiving actionable feedback grew to many hundreds of times per year.

From every example I have seen so far 4 cubicles cost more than a single Mob station.

In my experience the number of interruptions and meetings for a mob is reduced dramatically. Teams invite product owners to refine backlog while continuing to write code. Unless they are many mobs working on the same thing typically there is no need for stand up meetings because the whole team is already aligned. In general the team holds regular retrospectives and otherwise the code moves forward even if one team member does need to interact outside the mob.

I have worked in many environments and in each one prior to working as a Mob, I have found that 4 people working on 4 things leads to 4 different styles and directions taken in the code. This means a cost has to be paid by these 4 people to synchronize ideas appropriately. These costs are traditionally mitigated by creating coding standards, comprehensive documentation, and in many cases must be enforced by code reviews, or worse not enforced at all. This leads to things like a high variation in various aspects of quality between code produced by different team members.

Psychological safety as defined in Amy Edmonson's research is hard to come by on a team. I believe this exists to an even greater extent for teams that are not mobbing. In a mob you are forced to give feedback on items be it face to face or through general statements in a retrospective. It is very hard to avoid the people you work with and there is a greater incentive to establish psychological safety even though it is a difficult process to go through. If Psychological Safety cannot be established, the problems become extremely visible and transparent in a mob. The process of "debugging" the team becomes much easier when all of the interpersonal relationships are so visible.

I forget now who told me this but I found it so funny it stuck. "Solo development feels like sitting at home watching Netflix. Mob Programming feels like going out to a movie with friends. Pair Programming feels like going on a date." 

The amount of social pressure and dysfunction in a pair can be very high. Especially in awkward configurations like a senior and junior developer working together. I am not trying to say that there are no dysfunctions on a mob. A mob just has fewer opportunities for things to become dysfunctional. The amount of tension that is eliminated by adding a third person to team can allow the team to focus more on continuous improvement and less on one on one relationship that is casting them in the interpretation of their pair.

In Jason Kerney's experience report "Mob Programming – My first team" he tells a story about how he was afraid to leave the mob because he thought he would fall behind. The team was moving so fast that he would miss something important and people would think less of him. After being detained by someone who wanted to chat with him when getting some coffee he returned to the mob and realized he could still contribute and it was not very important to know what just happened because we had things like unit tests backing up our knowledge. The code could roll forward with or without him. It was better with him there but it was still produced without him there.

One of our visitors had said that mobbing felt slower but they were getting more done. They then compare mob programming to a "steam roller" It can feel slow but not matter how hard the problem is we never get stuck we just roll over it. In fact I hear more and more of this type of story. "It would have been harder and taken longer without mobbing"

During Agile Open So Cal 2019 I facilitated a session on Mob Programming Financials. The second highest dot voted item was the "optimal number of mob members."  First off i'll say that this was awesome because we had so many companies represented in the room who were all mob programming full time. The final consensus was 3.5 people. If 1 mob, 3 or 4 is good. For two mobs go for 7. Three people in a mob feels faster pace and eliminates more of the problems with pairing. When the team grows to 7 it is nice to have someone who can back up the rest of the team if needed.

My personal opinion it take take the "Law of Personal Mobility" from the open space conference format. "If you are not learning or contributing go to a different mob" I believe mobs can be any size as long as everyone is learning or contributing. With that said it usually ends up being 3, 4, or 5 in practice. Though I have heard of 20+ in production development mobs before.

No More Code Reviews

Finally the last thing I wanted to add here was the top voted item at AOSC19 for Mob Financials. The cost of doing code review to a team is so high done or not done that the group agreed it makes much more sense to Mob over solo or pair with code reviews. 

Code reviews can feel hostile, get ignored, or create a reduction in flow for getting items to production.

Do you agree? Reply in the comments below!