“All the brilliant people working on the same thing, at the same time, in the same space, and on the same computer” Woody Zuill
A few weeks ago, a co-worker proposed to experiment mob programming. I expected to enjoy this practice, I was actually delighted.
Context
We are a pizza team (3 devs, 1 BA, 1 QA) in an agile context, not working perfectly but striving to improve. We have an automatic delivery process and a code coverage around 80%. Collaboration is quite good and we’re trying to follow some BDD practices.
We decided to give mob programming a try to develop a new feature. Our job is to develop a library to communicate with some hardware whose data model is changing. Our target is to be compatible with both versions of the model with no impact on end users. 
Initialization
We did it in a meeting room, not in an open space. We had a computer, a big screen to display the code, two keyboards and two mouses allowing two developers to code without having to switch.
We also had a smaller screen to display useful technical or business data, and a big whiteboard.
Expected
The collective intelligence emerged. Questions and answers kept on coming. We drew the big picture, and saw which implementation choices we had. It was crucial to discuss with the domain experts the why of the model evolution, it allowed us to understand the business impact expected for this feature.
The test suite showed again how useful it is, we saw the impact of our choices within a few seconds. It was interesting for the BA because he had never seen these red/green lights in action. We refined our Ubiquitous Language, and it allowed our domain experts to understand our implementation, just looking at the code with us.
It was exhausting, much more than pair programming. In a mob, there is always someone or something to bring your focus back. It’s really productive, but it’s unsustainable if you don’t manage regular breaks.
Business experts were really involved, they were focused to understand and challenge our implementation choices. We challenged them back on some business terms and use cases.
They were reassured because they see how we technically deal with the problem.
We went out of our comfort zone together.
Actual
BDD is about communication, and communication is about (professional) empathy for your co workers. You want to understand their perspective to (well) solve the (right) problem together. For this reason, mob programming is the best BDD implementation I know.
No framework, no process, no bullshit. Just bring the 3 Amigos (or more!) in one room and focus all together on one specific issue to solve.
Even if it was meant to be a hard problem to solve, we needed only a few days to find a satisfying implementation. Put enough knowledgeable people in the same room, let them produce code and you will obtain a robust and well understood solution quickly.
Think about it, how many useless meeting do you usually attend to grab enough knowledge to implement something? And what do you produce with this knowledge? Word specifications and/or powerpoint explaining the workflow? How effective is this knowledge transfer? Remember the first principle of the manifesto?
“Individuals and interaction over process and tools. ”
Exception
“Do we need some meetings first? “
Absolutely, don’t do it if the topic is absolutely unknown. You need to have enough knowledge in the room to explain the problem and think about a few solutions.
A method like event storming would be more useful to explore the problem. You can’t just jump into the code, you have to explore the problem first.
But don’t look for the perfect solution during this exploration phase. I would even argue that you can’t find the best solution during this phase. The goal is to grab enough knowledge to understand the problem, and think about options.
Teardown
It was definitely a really good experience, and I’m looking forward to do it again. There’s still lots of unchallenged habits in our traditional ways to develop software.
It makes sense to get people who know what to do and people who know how to do, in the same room, and let them build something all together. No Word/Excel/PowerPoint document will create value for your Company. Why not just remove them from your process?
Invest on methods such as Living Documentation instead, to generate documentation directly from your code. Get a documentation which is a true representation of what the software is, intrinsically.
Mob programming is definitely a new good habit I’ll try to share with other passionate co-workers.
Thanks to my team for the experiment, and to my reviewers:
Charles Bouttaz
Jean Helou
Nadège Rouelle
Maxime Sanglan
Woody Zuill