24 Months of mob programming
Like many of the software teams at Nordnet, the app team practices mob programming and have done so for 24 months now. We have been doing everything from discovery, ideation, interviewing, onboarding, coding, designing, and every other task that you can think of at a modern tech company together, as a mob. For most of the time the mob format has felt natural and easy to use but sometimes it has felt difficult and unnatural. This post is about our shared experiences, ups and downs, writing the Nordnet mobile app together every day, for 24 months.
TLDR
- Mob programming enabled us to triple our release cadence.
- Mob programming helps us to get into the flow better than when working solo.
- Mob programming is a skill, it requires a lot of work to get good at, so we needed weeks rather than days when we were evaluating it.
- Mob programming is just a tool, however it is a very powerful tool.
How we started mob programming
The team had tried mob programming previously, before we started using it full time, with varied success. The difference back then was that it was used sporadically and quite often for unusually difficult tasks, which is necessarily not a bad way to go about it. One of the core ideas behind mob programming is that a team of programmers is stronger together than any individual is on their own, so using the mob format for unusually difficult tasks is a great use case for it.
However, it is probably not where a team wants to start when they are new to working together in this format. That is because, much like anything at work, mob programming is a skill. When you start out trying a new skill for the first time you are most likely going to have a hard time, simply because you are new at doing it. Which is okay! It is fun and engaging learning new things. Especially new difficult things. But, it is more fun and engaging if you start off under the right conditions.
Nordnet frequently invites talented speakers on different topics, and one rainy week in November 2020 Woody Zuill[1] visited us to talk about the power of mob programming. The team felt inspired, and eager to try it out after the talk so we laid out a plan during our last zoom call before the weekend that Friday afternoon. We had decided that if we would try mob programming again we should sit down and program together for at least one major feature and then evaluate after that. So, come Monday morning, we all joined the same Zoom call and started working on the same feature.
The feature we were building was nothing special, it was just a way for customers to receive and read messages that our Customer Service team sends out. But the higher difficulty and the larger scope of the task meant that it felt like a perfect opportunity to try out mob programming. If the feature that we had decided to build together had felt too easy or too difficult then it would’ve been problematic to evaluate our new way of working. But this particular task we felt hit just the right spot in terms of complexity.
About four weeks later we had the feature in place and out in production. We felt hooked with our new way of working because it had enabled us to move faster, share knowledge between each other, and have shorter feedback loops (no more code reviews).
But… mob programming is inefficient!
One of the more common arguments against mob programing is that it is an inefficient method to write software. For example, one might say:
“Why do you have 3–5 developers working on one thing at the same time, when you can have 3–5 developers working on 3–5 things at the same time? That way you could get much more tasks done in the same time as it takes to finish one task!”
However, we found that this was simply not the case. Doing loads of tasks at the same time created it’s own set of problems. Like only one person knowing how a particular feature worked, context switching between it all, and the need for different types of sync meetings to try to solve the forementioned problems. Narrowing down on only 1–2 tasks allowed us to have a higher focus, deliver with a higher quality, and be more productive.
Quantifying productivity is tricky and there are many factors to it, but if one looks at the release cadence before and after we started mob programming, it paints a pretty good picture that practicing mob programming lead us to develop new features, more efficiently:
We don’t think that it’s this easy though. We didn’t just start mob programming and then see our release cadence triple over night. Mob programming helped us with improving our release cadence, but it was not mob programming itself that did it.
We found that working in this closely collaborative way, having few tasks ongoing at the same time, and having shorter feedback loops, made it much easier to improve on our other processes. Mob programming effectively enabled us to see other ways in which we could improve.
Getting into the flow
One discovery that we did not anticipate, was how much easier it would be to end up in a state of “flow” during a mob, than when you were working on your own. By “flow”, we mean that special feeling when the level of difficulty and your level of skill matches up perfectly and you enter this completely involved & focused mental state, where time just flies by. I think if you have done some form of development we’ve all experienced this, it is probably one of the reasons many of us chose this profession to begin with, since being in a flow can be very enjoyable and highly addictive.
If we depict difficulty on one axis and skill on the other, just like in the figure above, then flow is what happens between those two areas. If a task is too easy, then it might feel a bit boring or mundane; If a task is too difficult, then it might feel hopeless or anxious. The trick to entering a flow state is to work on a task that sits right in that sweet spot. We believe that it is easier to find that sweet spot in a mob, in comparison to working alone because you are able to help each other out in real time.
We are all good at different things and we all have different types of skills, so it’s easy to pick each other up and that way widen the sweet spot where flow happens.
Learnings & challenges
We’ve had many successes and good experiences from working together in this way, but it is still important to remember though that mob programming is a tool, much like anything else. It is not a way of life or something everyone has to practice every day, 8 hours per day. It has, however, turned into a good default for us, and we’ve seen that basically every single metric has improved since we’ve started mob programming and as we get better at doing it. But all good things aside, much like any method mob programming has it’s own set of challenges, here are some of the ones that we’ve faced:
- Too big mob sizes, we found that when we were over 4 it hurt us more than it helped us.
- We all have different preferences to doing work, and mob programming is not for everybody.
- Having more than one mob developing features at the same time creates new problems.
These are some of the learnings that we’ve had:
- With mob programming it is easier to adjust and improve on the teams processes.
- It instantly solves common software engineering problems, like knowledge sharing, syncing between team members, and removes overhead.
- It is a social way of working, and a great way to satisfy your social needs during remote work.
If you are eager to try out mob programming in your team then our recommendation would be to evaluate it over an extended period of time (don’t just do an afternoon). Try to look at it as a way to enable your team to remove obstacles that you haven’t been able to remove before. Oh, and have some fun with it! Working like this is, above all, a lot of fun!
[1] Woody Zuill webpage: https://woodyzuill.com/#speaking
