Article summary
I’ve been reflecting on how my current team is both super-productive and fun to work with. One key element of this is that we recently started to practice mob programming. We did this organically without actually knowing what the practice was, but we have since learned how to apply it in certain situations. The results have been extremely positive.
Full disclosure: Before writing this, I’d never even heard of mob programming. I was doing some research and discovered that the collaboration model our team adopted has a name, and the internet is full of opinions about it.
Stumbling into Mob Programming
I currently work on a team of five that’s responsible for a lot of things, including:
- A React front end
- Native mobile front ends (iOS and Android)
- A shared Node API/backend
A few months ago, we noticed that we were starting to accumulate some knowledge silos. In one of our sprint retrospectives, we made a decision to try to break down these silos.
Our strategy at the time was to do more pair programming. This certainly worked, and we still try to pair whenever it makes sense. However, we also serendipitously stumbled into mob programming.
We were about to begin a new sprint and start work on a large new feature. As we usually do in this situation, we gathered our team around a whiteboard and sketched out some architectural ideas. Then, instead of splitting up individually or into pairs, we did something different. We spent an entire day where we all worked together developing some of the initial architecture for the feature.
This process was essentially like pair programming, but with more than two people. The next day, we continued to work together for a bit, then we split up into pairs for the next few days to finish the work.
In our next sprint retrospective meeting, we reflected on how we really liked the flow of the sprint. We completed the new feature with a high shared understanding. It felt great. We also noticed that it resulted in increased shared ownership of the feature we developed and less individual stress.
We have since applied this approach in a few other situations, namely when working on bugs or investigating critical issues.
Deeper Reflection
In many ways, the concept of mobbing or swarming isn’t new. We already do it all the time when we groom the backlog, estimate stories, or hold any type of team meeting.
We mob in these situations because it’s the easiest way to transfer knowledge and collaborate with the entire team. It seems reasonable that this type of practice might bleed into development a bit.
I don’t think that mob programming should be used all the time, but like most things, when used appropriately, it seems to be extremely beneficial.