3 compounding benefits of mob programming that make it cost-effective
Mob programming requires time to get used to it. With practice, though, you’ll discover unexpected and compounding long-term benefits of mob programming.
As a technical agile coach, I practice mob programming in 2 contexts.
First, I coach teams through mobbing.
Second, I mob with the other coaches to practice and prepare katas. We are also mobbing on different topics:
- To increase skill sharing.
- To avoid delaying work because of our individual constraints.
Through experience, we discovered some unexpected long-term benefits of mob programming:
- Mob programming reduces the amount of work to do
- Mob programming makes continuous improvement more effective.
- Mob programming improves design discussions.
Let’s go through these in more detail.
1. Less work to do
I attended his talk about #NoEstimates at NewCrafts Paris. He asked us to estimate the time it would take to resolve a small math puzzle. He then asked us to solve it and compared the time it took us with the estimate. He did a few iterations of this with variations of the puzzle.
The conclusion was that the amount of work does not depend on how complex the task looks, but more on:
- our knowledge about the domain
- our understanding of previous solutions
Any developer who has worked on legacy code knows that even simple features can take months to build. This is for two reasons:
- We are often not familiar with a legacy system’s design
- The legacy system’s design is often unnecessarily complicated
As a result, tiny changes can have significant undesired consequences. In fact, these 2 dimensions are what drives the long-term productivity of a team.
Here’s the thing: Mob Programming both builds knowledge and simplifies the current system. Let’s see how…
Mob programming makes the code base smaller.
20 years ago, Alistair Cockburn did a study on pair programming. It concludes that pair programming makes the codebase at least 10% smaller. My personal experience backs up this study. I would even have estimated the gain to be more than 10%.
This results from more knowledge about existing code in a pair of brains than in a single one. Two developers working together spot more opportunities for reuse. In the end, these small reuses compound and make a significant impact on the codebase size.
Mobbing has an even more significant impact, as there is more knowledge in a mob than in a pair.
In the end, a smaller code base is easier to work with and makes adding new features faster.
The mob is allergic to debt.
Another benefit of mob programming is that it makes debt evident and unbearable. Debt slows you down for stupid things. Debt is always painful, but it becomes intolerable when the full team works together.
Suppose your build is slow. Every time you build, all the mob is going to wait, doing almost nothing. It won’t take a lot of these group ‘breaks’ before the team decides to tackle this slow build.
As a result, the system remains simple and easy to extend.
More knowledge sharing happens in the mob.
There’s not much to explain here. Working together on the same task will share knowledge about the current system.
When a new feature request comes in, the mob will have as much knowledge as possible to build it. As a result, it will be ready sooner.
It compounds!
Here’s the most exciting thing: these benefits compound over time! In fact, they even support each other.
Over time, this makes a massive difference in both
- the system’s complexity
- the team’s knowledge about it
As a result, features that would take days to build in a traditional team only take a few hours.
2. Continuous Continuous-Improvement
I wrote before about how retrospectives only take us as far as known best practices. As an alternative, I’ve had great success using the improvement kata.
Since then, I’ve also used the improvement kata on my personal tasks. It has proven even more useful. It has helped me to design a productive and sustainable pace. Currently, in these times of lock-down, it’s also helping me to get a grip on the new situation.
Finding data
Unfortunately, gathering data can be a real challenge. The improvement kata is a data-driven technique: no data means no improvement!
Sometimes, you will manage to extract the data out of your existing tools. In the past, we managed by digging data out of JIRA. That’s also what many data-driven tools are doing (Code Velocity, IdeaFlow…). (BTW, these tools are, in fact, packaging the improvement kata around a particular problem. This might be an interesting post!)
When you have a specific problem and no data, you’re kind of stuck. Collecting data should not be that difficult! Gathering data on my personal tasks is very easy. I just make sure to log what I need every day for a while. A simple spreadsheet is enough. After a few weeks, I’m able to accurately understand what is going on. I can then try and measure the impacts of experiments.
The teamwork challenge
In a team, daily data tracking is a lot more complicated. I’ve always had a hard time getting the whole team to log data. Team members might not all agree on the importance of the problem. Some others might have something else in mind. And some might be afraid of the big-brother potential of this practice.
One solution is gamification. For example, Joe Wright used stacks of lego bricks to represent time. That’s a friendly solution when it works. Unfortunately, sometimes it’s not possible:
- Lego bricks won’t help you if your team is remote.
- If you need small-grain tracking, you might never have enough bricks.
It’s a lot easier in a mob.
In a mob, this problem disappears. A single team member caring about data tracking is enough! The privacy concern goes away too. We are logging the mob’s activity, not that of individual developers.
We might also wonder if this is not a return to old-style command and control process improvement. I’ve seen this in practice. It does work, but at the cost of high turnover and disengaged programmers.
Disengaged employees are 34% less productive [Forbes].
Mob-style continuous improvement has nothing to do with this. A mob is empowered and autonomous by design. This actually increases engagement! Mob-style continuous improvement will just blow the old-style process improvement away.
It compounds!
Even a modest 1% improvement per month will become massive in the long term. The Coronavirus epidemic should have taught us the power of exponential growth!
3. Higher quality design discussions
The smart keyboard
Here is the central revelation I got from Woody Zuill’s mob programming masterclass:
The developer acting as the driver is a ‘smart input device.’
Like a genius keyboard! He takes care of compilation issues, semicolons, formatting, and a lot of other stuff.
Let’s go through an example. A few weeks ago, we were practicing the roman addition kata. I was driving when the mob asked me to rename the tests using some uppercase letters for roman numbers. We had names all our tests xxx_plus_yyy_is_zzz. As a smart keyboard, this renaming fell in my area of responsibility. I checked the internet to know if Intellij could do some uppercase regexp / replace. It turned out it could! I worked in parallel with the rest of the mob. My colleagues were following some higher-level discussions. I worked out my regexp and did a global file replace.
Now that I master uppercase regexp replacements in IntelliJ, I can say that I’m a smarter keyboard. Not only this, but the whole mob knows that the driver can deal with similar queries in the future.
Higher-level programming
Text replacement is a straightforward example. The same phenomenon happens around coding standards, conventions, work habits, and even language.
- The more the mob works together
- The more it grows its own folklore
- The more the driver understands high-level queries
- The more the rest of the mob can have high-level discussions
- Eventually, the more productive the mob is.
It’s a bit like if the driver was raising the level of abstraction of the programming language. Similarly to a higher-level language.
Here is something Fred Brooks states in The Mythical Man-Month:
Developer productivity, in lines of code, is independent of the programming language.
This means that if you can write 4 lines of assembly in 1 line of C, switching to C will make you 4 times more productive. Similarly, if the mob driver lets you write 4 lines of code in 1 instruction, then the mob is 4 times more productive.
Granted, measuring productivity in lines of code is not a good idea. Still, the logic explains why Mob Programming is not as slow as we could fear.
It compounds!
Don’t forget: the more the team mobs, the smarter the driver becomes!
Seriously… how can mob programming be productive?
We’ve seen 3 unexpected benefits of Mob Programming. Still, mob programming remains very counterintuitive! Selling mobbing to your boss or colleague will always be a hard bargain. I’m not the first one to try to explain this, for a larger perspective, have a look at these posts:
There are so many variables in software that measuring productivity is almost impossible. What we can do, though, is to check how the unexpected benefits I mentioned earlier make a better case for mob programming.
Long term impact
The first thing we notice with these unexpected benefits is that they compound!
If you ever read a personal finance book, you’ll know the importance of compound interest. The same goes for mob programming.
The glitch is that there is an initial cost to mob programming. A good strategy is to start with only a few hours of mobbing every week until the team gets good at it. You can then slowly raise the ratio. You could even start with a coding dojo before production work mobs.
As the long-term benefits compound, the mob will become more and more productive. More productivity means more features for the users and a sustainable pace for the team.
Be careful, though. Full-time mobbing might not be suitable for everyone in the team. Some people, especially introverts, will need some solo time to recharge batteries. You can get the perfect ratio for your time trough trial and error…
But you can also have a structured conversation!
A business case for mob programming
At Murex, we tried a business case for pair programming with a team. We went through this course, Making the Business Case for Best Practices. We extended the pair programming case to take a ‘ratio’ of pairing time. This allowed us to take into account a team member who was very reluctant to pair program.
We found out that the optimal ratio of pair programming was around 20%.
Between 0% and 20%, the benefits of pairing grew. Past 20%, the moral tax would be too heavy on the team!
A business case makes it a lot easier to discuss this kind of issue a priori. It’s challenging to voice your burnout to the team when all the team in enjoying pairing.
We can do something similar with mob programming. The Pluralsight course does not include a section on Mob Programming. With fellow technical coaches, we brainstormed the costs and benefits of mob programming. Here is what we found at the time:
Benefits
- Pair programming Benefits +
- Reduced time spent in daily meetings
- Reduced time spent in sprint planning/backlog grooming meetings
Costs
- Adapting management practices
- Whole team doing the same task
- Mobbing setup
- Morale dip
We could now also add the long term compounding speed up. Unfortunately, I don’t know how to measure it. My best shot would be to brainstorm a speedup of X% per month when working as a mob. A human-friendly way to think of exponential growth is ‘How many months for it to double?’.
For example:
If a team did work 4 hours per day as a mob, I could expect its productivity to double every year. You can then use the Rule of 70 to deduce your monthly speed up. In our example:
70/12 = 5.83%
This means 5.83% more features every month.
We could then complement the business case with this figure. As Erik Dietrich explains in his course, be ready to play with this number until everyone is ok with it.
This exercise will not only help you to sell mob programming to your boss or team-mates. It will also show you what you are trading off between solo and mob programming. It will help every team member to take a step back from their personal gut feeling. Eventually, this will trigger more in-depth discussions. It’s a bit like a Big-O analysis for best practices.
A new way to split the work?
If the compound effect and the business case still did not convince you, let’s try another story!
Here is yet another way to think of mob programming. Mob programming makes up for work parallelization by reducing mental task switching.
Let’s go over all the different tasks we do when we program:
- Type in some code
- Run compilation
- Fix compilation errors
- Reorganize code for readability
- Think of design (at function and at larger scales)
- Apply automated or semi-automated refactorings
- Think of performance (at function and at larger scales)
- Write tests
- Think of edge test cases
- Keep track of where you stand on the main task
- Run tests
- Run the app
- Debugging
- Write down things that we could improve
- …
This sheds new light on ‘focused solo programming.’ We are not that focused! We are continuously task-switching from one activity to the other.
Let’s look again at the long-term benefits of mob programming I mentioned earlier
- in 2, Continuous Continuous-Improvement. One person focuses on continuous improvement
- in 3, Higher quality design discussions. One person is typing, building, and doing many low-level activities. The others concentrate on design
Woody Zuill explains that mobbing enables the mental state of ‘flow.’ The driver is taking care of all the low-level details of writing code. The rest of the mob is left with:
- Thinking and making decisions about design
- Thinking of performance
- Deciding about the next test cases
- Keeping track of where you stand on the main task
- Keeping track of things that we could improve
That’s already an impressive reduction in Work-In-Progress! But wait, there’s more! You can decide to focus on a single topic, with the assurance that others in the mob deal with the rest! For example, you can concentrate on continuous improvement for half an hour (cf point 2). Or you could spend some time thinking of edge cases for tests.
In the mob, you can stay in the zone!
The first thing we can see is that the same work is happening in both work configuration. Let’s now count how many context switches the team goes through during this 20 minutes work session:
- working solo: 28
- as a mob: 10
This is 3 times less. Even if these micro context-switches only cost few seconds each, this is enough to explain how a mob can be more productive than solo developers!
I’ve already seen this pattern!
To run fruitful meetings, Sociocracy suggests setting up different roles for attendees (Secretary, Leader, Facilitator, Delegate…). Maybe we should try to explicit ‘roles’ in the mob and see how this works? I could think of:
- The tester
- The continuous improver
- The ‘performancer’
- The maintainer
- The tracker
- …
Nick Tune suggests a similar scheme for Remote Team Flow EventStorming for Retrospectives. They managed to run a remote Flow Event Storming by using a few of these roles. To avoid overspecialization-blindness, they round-rob these roles every 10 minutes.
I’ll write about this as soon as we get the chance to try this, so stay tuned!
What do you think?
I’d really love to read about your own experiences with mob programming.
Maybe you:
- Noticed the same effects I have mentioned?
- Experienced other surprising long-term impacts of mob programming?
- Have experimental data to back up some of these effects?
- Noticed the exact opposite of what I wrote about?
- Or found new ways to sell mob programming to your team?
Whatever your story, I’d love to read it in a comment below.
Happy mobbing!
Leave a comment