But it has to be applied in the right way for the right reasons
Listen to the audio version!
One year ago, I wrote about Pair Programming. I described how to find the best context to apply it, how it looks in practice, and how to do it incorrectly.
Similar to Pair Programming, there's another approach to software development called Mob Programming.
Note: This post assumes the practice of Mob Programming when all participants are present in the same room using the same computer. That doesn't mean it can't work in other contexts such as when you're working remotely with Open-Source, as Philippe Bourgau pointed out in this useful comment.
Every time I talk about Mob Programming, Woody Zuil comes to my mind. For those who don't know, Woody is the author of "Mob Programming — A Whole Team Approach." I was very fortunate to meet him after YOW 2016 when he was invited by Guilherme J. Tramontina from Pragma Team to give us this talk:
The YOW! 2016 Talk: Woody Zuill — Mob Programming, A Whole Team Approach.
Mob Programming is excellent but doesn't work for every team. It requires at least the same mindset of Pair Programming from every participant. If done correctly, in the right context and for the right reasons, it can move the team forward quicker. However, if done incorrectly, in the wrong context or for the wrong reasons, it can have substantial negative consequences.
In my experience, there are some things that tend to happen which can make Mob Programming not to work as efficiently as it could. However, be advised that none of the things that will be mentioned here is an excuse to dictate the team’s behavior. Mob or Pair Programming are not going to work if people feel they’re being forced to do it.
Mob Programming is where the whole team — and that includes tester, product owner, and designer — work together on one task at the same time on the same computer.
In the Mob, if you notice a point where you don't understand anymore the purpose of what's being done and stay quiet, the lack of understanding will only increase over time. If more members stay like that, the less effective the Mob Programming exercise will be.
Everybody needs to understand what is being done. If it looks like there are assumptions someone has that you don’t, ask questions to regain the context. There's no cost in asking a "dumb question", as long as it's done as early as possible and is related to the task that is being worked on.
This is why Mob Programming doesn't work for all teams. To be effective, you need to be comfortable to ask questions in front of all the team.
Ask questions as early as possible if it looks like you lost the context.
Just like Pair Programming, there's the Driver and the Navigator. The Driver handles the keyboard and the Navigator helps the driver with directions. The difference is that there's one Driver and everybody else is a Navigator.
It's very common for a team to start doing Mob Programming because somebody wants to show something to the whole group. One person holds the role of the Driver and the Navigator. Everybody else watches to learn from them. However, that misses the point of having everybody actively participating on the work.
Watching somebody do the job is not Mob Programming.
If you leave the session temporarily and come back again later, you’ll lose the context of what has been done in the meantime. The cost for the team to explain everything will be more significant than pairing. The cost increases as more people leave the session frequently and as more time passes after they went out.
Of course, people have to take breaks for many reasons, like to grab a coffee or go to the bathroom. However, you can agree as a group that somebody becomes the driver automatically after they leave and come back. The driver can understand what the group is trying to achieve after a few minutes on the keyboard.
Rejoining the Mob as the Driver means that the cost of disruption is null and the flow is constant.
Prefer to rejoin the Mob as the Driver.
It’s very important that everyone pays attention all the time. Also, as mentioned in a previous post, owning the keyboard and doing the work (direct and purposeful experiences) can have a better knowledge retention rate than watching somebody do something (verbal and visual symbols).
For those reasons, sharing the keyboard continuously makes sense. A good pattern to validate focus is to select who's becoming the Driver randomly. This way, it's less likely somebody won't pay attention due to the risk of looking unprepared when they're called upon.
Of course, there are exceptions. And again, it depends on the team.
A Product Owner, for example, doesn't need to be the Driver if the team is focused on a task that requires active coding, but they can give input if the team is going in the right direction. The same way, an engineer can work with Photoshop under the guidance of the Designer or Product Owner.
The effectiveness of Mob Programming is maximized as each member of the team is multi-disciplined and capable of doing the job of anybody else. However, it's very hard (if not impossible) to find a team member skilled like that in today's market.
To be more effective, Mob Programming needs everybody to touch the keyboard frequently.
Mob Programming challenges everything.
It doesn't work for everyone. Every team member needs to have some specific behavioral attributes, which is similar to Pair Programming.
It’s very important to run it correctly and discover if it doesn't work as early as possible. Failing to do so can incur a huge cost and serve as a Confirmation Bias to the ones that already have a negative opinion about it due to past experiences with poor execution.
Mob Programming is a very powerful tool that can increase the team's overall throughput and remove the work in progress completely.
It makes you and your team more effective, as long as you try to avoid some common mistakes.
Are you up for it?
Thanks for reading. If you have some feedback, reach out to me on Twitter, Facebook or Github.