Last week marked the day when I've been mob programming full time for a whole year. In case you don't know what mob programming is, Woody Zuill, who is credited for discovering the method describes it like this:
"All the brilliant people working on the same thing, at the same time, in the same place, and on the same computer."
In short, it means that you sit together with 2 or more developers and work together on one computer, in a similar fashion to pair programming but with more people. This might sound counterproductive but in reality, it's a very effective way of working. If you want to learn more about the why and the how of mob programming I recommend watching Woody's talk from GOTO conf 2017.
I've really enjoyed discovering mob programming this past year so I wanted to write down some of my key takeaways.
Processes
When you work as closely with your team as you do when you mob program, it turns out that lots of processes are unnecessary.
- No pull requests or code reviews since that is done "live" during the day.
- We very rarely work in feature branches since the mobs most often don't work in the same part of the application at the same time.
- The daily sync meeting is mostly for the benefit of product owners who wants to know how we're doing since everyone in the team is on the same page already.
When mob programming, all of these feel more like bloat and obstacles in the way of delivering value. I dread the day I'll have to go back to attending unnecessary meetings just because someone needs to "talk something through".
My best code
I'm quite certain that I've written my best code ever this past year and I attribute a lot of that to the fact that my code has been constantly code-reviewed, that I've learned so so much from my colleagues and that we (almost) never get stuck.
Most of my time nowadays isn't even spent at the keyboard, but rather in a chair to the side discussing the problem we're trying to solve. In the same way as learning by teaching is a great way to learn, constantly discussing the code I write is a great way for me to improve.
And while it might be rewarding to be stuck on a problem and struggle with it for some time before finally solving it, not getting stuck in the first place beats it. There is always someone in the mob who has an idea of how to solve the issue and since everyone is in the loop already, you don't have to explain the context when discussing it.
Hopefully, I've also helped my colleagues write the best possible code and taught them something along the way.
Interpersonal issues
Working this close to other people all day every day isn't just hunky-dory though. It also means that interpersonal issues rise to the surface quicker than they might otherwise do. While I do see this as a net win, it also requires that everyone dares to be vulnerable, open up and discuss their feelings.
This is something you have to continuously work on if you do mob programming. It is extremely important to build a team where everyone feels safe since so much work is done closely together.
However, regardless of how your way of working looks, your team will perform better if they dare to open up to each other and be vulnerable. There are a lot of resources out there about this but I recommend everyone to read the book Dare to Lead by Brené Brown.
“Leaders must either invest a reasonable amount of time attending to fears and feelings, or squander an unreasonable amount of time trying to manage ineffective and unproductive behavior.” － Dare to Lead
Scaling is hard
I joined the project as my current team grew to six developers, and today we've grown to a total of nine. In my opinion, this has been one of our biggest challenges and is something we still struggle with.
When we were six people we usually split into one or two mobs depending on if someone was sick or working from home. This worked great. We didn't have to spend time syncing what the others did since we sat so close together and almost always worked on the same thing. Now that we're nine and have added just one more mob station so that we usually split into three groups, some of the benefits of mob programming are suffering.
We immediately get some knowledge silos since some people end up working on certain parts of the application for a longer time than others, and hence learns more about it. There is also more overhead communicating between us. It's surprising how much of a difference just one more mob does to the ability to keep track of what everyone is doing.
If you have any experience scaling a mob programming team I'd love to hear your thoughts.
In the end
Mob programming might not fit everyone but I do think that it is an excellent tool to use as a developer. I've had an extremely fun, rewarding and developing year. Let's hope the next one is just as good :)
Top comments (13)
Hey! Some questions about this.
Can all people find a time where to speak?
Nobody is unfulfilled because they have a feeling of not been heard?
How do you take care that everyone in the group has time to speak and shine and not being afraid to do it?
I'm thinking about that because I have been a junior dev (and a girl in bonus), and sometimes it is not easy to be heard by old devs 😅 ...
Hi! This is a great question, thank you!
For me, it hasn't been an issue, but then I'm very heteronormative (white, cis, etc). With that said, from my perspective it's all about building a culture of trust. You have to create a team where everybody feels that they can speak up, talk about their feelings, ask "stupid" questions without being judged and so on. One key point in this is making sure everybody understands that if someone learns while in the mob, they are contributing to the mob. Mob programming isn't about producing the most lines of code or the greatest quality (even if that is often a perk), it's more about working together toward a common goal.
However, as I touched upon in the post, interpersonal issues will often rise to the surface when doing mob programming. This also means that there is a risk that things like sexism, racism, ableism or any other -isms; no matter if it's unconscious, structural, or whatever, might also rise to the issue. I can't tell you how to handle this if it happens, I haven't experienced it so I can never put myself in this position. What I can tell you is that in my, limited, experience you need to have a focus on working on these things. You can't just start mob programming and hope it's gonna work out, it won't. You need to put the work in to get the benefits. You need to make sure everyone understands that everyone can learn for anyone, that there can't be any prestige in the mob, that the purpose isn't to show whos best but to deliver value to the organization.
And just to repeat myself a bit, I wholeheartedly recommend reading some books by Brené Brown or watching her special on Netflix.
Please let me know if you have any more questions or if something is unclear, I'd love to chat more about this!
Thanks for your answer!
I'm happy to see that this Netflix doc is on Netflix France too! I'll take a look at that and the other books, this is super interesting.
I think to talk about all of that before the mob programming, what are the limits and what the objectives and the end could be a good idea to start.
We've started to do something similar yesterday to my job to learn about new tools we want to use in every project and learn also Elixir. ATM, it was only the setup of the project so nothing special, but I let you know what we learned with that and if I have more inputs for these issues.
That sounds great, looking forward to hear how it goes! :)
Great idea, Im trying to get my team to work closely together. I often use the term "swarm" on problems, which is very similar to what you described here.
I really like that term! Might borrow that when talking about this :)
Similar here, we have occasional swarms when something extra ugly needs attention, probably ought to do it more regularly for less exciting moments!
Wow, what an experience!
Wow this must have been extremely exhausting!
I pair-programmed full-time for a whole year and I would end up completely knackered every day
For the first couple of months, I was completely exhausted when I arrived home but after that things got better :D
Great article - I'd certainly been keen to read more detail about how your average day-to-day (and week=to-work) plans out in terms of who does what, etc!
Thank you! I've done a talk about this before so I might turn that into a post as well!
It's a great experience and my team do this once a week, in a dev class. Hardly doable for us if this happens on a daily basis.