After a particularly rough couple of months last year, our team (of six) decided it was time for a radical move. At the point we were so downtrodden that our small hope that it would at least provide something new was enough of a motivation for us to decide on a two month experiment: we would try mob programming.
The How
Mob programming is pair programming taken one step further. The entire team gathers around one (preferably big) screen, take turns sitting at the keyboard, and work on a problem together. You can use it for solving just the one bug, you can do it a few times a week, or you can go all in. We went all in.
We hooked up one of our computers to a projector, faced a couple of desks the same way, and started to tackle all our problems together. Really, ALL of them. We coded together. We answered mail together. We handled emergencies together. We took breaks together. We did not go to the bathroom together, but we might almost as well have. At some point we started referring to ourselves as “the collective”.
Progress at first was a slow, hair-pulling, nail-scratching experience of finding out exactly how far we were from each other in terms of preferred methods, architecture ideas, typing speed, shortcuts (imagine sharing your shortcut setup with five other people!), knowledge and talkativeness. The first two-four weeks were more or less excruciating.
The Benefits
Work never stopped. Someone home sick? Someone leaving early? Not a problem. The mob was always there, ever moving on, like a scary blob creature.
Knowledge sharing increased by bounds and leaps. After a ridiculously short while we all had access to the total shared knowledge of the team members, since we all had to go through each other’s motions. We knew all the quirks of someone’s newly built service, we extended our knowledge of nifty shortcuts, we learned to deploy. Our testers learned to code and script beyond what they had done before, and our developers learned to adapt a much more test driven way of thinking. When you yourself have to performance test your service, you build a more testable service.
We no longer have different ways of deploying to production, writing tests, exploratory testing, or most other things you can think of, instead we are all doing it together. What’s more, this means that we get to hear all those little smart ideas and tricks that were contained in people’s heads in the past, and they become part of a new and improved way of doing everything.
The overhead got removed. All of those little sync things are no longer an issue. You have in issue you need to bring up with your team? Instead of waiting for a standup or calling a meeting, you just open your mouth. Chances are good that your team members were just about to do the same thing, since you stumbled on the issue together. Everything gets resolved as it is brought up, saving you both time and emotional effort.
Anyone could go to any meeting. Since we all knew exactly what was going on with everything we did, any member of the team could represent in any meeting.
Our tooling improved. When working together like this every minute is precious, and laborious manual procedures that you just buckle down and get done as an individual can no longer be tolerated.
Individual weaknesses could be overcome. When you all have to think and work through each other, your weak points become exposed very early on. Instead of hiding them from your team members, they become obvious to everyone, and thus dealt with. We found that we very quickly evened out the playing field of individual shortcomings.
Interpersonal issues and friction had to be resolved. When interpersonal issues happened they get brought up much more quickly. In a ”normal team” when there are these types of interpersonal issues they are often allowed to fester. People who have issues only need to deal with each other for limited periods of time, so they just grin and bear it. This isn’t really possible inside of the mob because you would go completely insane.
Stress levels dropped. When responsibility was suddenly explicitly shared across the team, individuals no longer felt as guilty for the entire team failing. Weaknesses were exposed very early, and handled before they could fester.
We became more daring and forward. When you are facing obstacles together rather than individually, it is a lot more easy to make brave decisions. You decide to override a rule or kill off a service together, and as such you know that it is defendable and that your team members will always have your back.
We became friends. Well, we were friends earlier as well. But having to actively work on a close relationship with a group of people forges friendship, and in the long run we found ourselves closer than we had been before.
But this can’t possibly be efficient?!?
We are starting to get used to people looking at us like were crazy when we talk about this, and they are always certain that this can’t be efficient.
Here’s the crux of it, typing isn’t the bottleneck in software development, and writing code isn’t building a product. The real cost is solving the problem, waste, and rework. Mob Programming addresses all those things and more.
What have you got to lose?
We aren’t claiming this is perfect, or it will be the best way of working forever, or that this will work for every team. But the benefits we have seen have far outweighed the initial pain that it caused and has moved our team to a whole other level. We are happier, more productive, and more knowledgeable.
Even if you don’t believe any of this could possibly work we would argue it is worth a short experiment to find out. At the very least we promise you’ll learn something about yourselves and your team.