The people speaking and using Mob Programming are not legion. Despite this their experiences are mostly valuable due to the divergent perspectives they have regarding coding and teaming.
Llewellyn Falco gave a keynote on Mob Programming during the first Mob Programming Conference, called "Understanding the Science of Mobbing". The Mob Programming Conference took place in Cambridge, MA, May 01-02 2016. InfoQ is covering the event with Q&A and articles.
According to Llewellyn, Mob Programming is not a science -and Computer Science is barely one either. There are nonetheless some common practices regarding how a team develops software:
- Solo programming is the most common practice today, and everything gets into the code, bad or good,
- Pair programming is the second most known way to do it, and the better ideas of two get into the code,
- Mob Programming is probably the least known way to develop and, as Llewellyn put it - It's not getting the most of the people but the best
Where is the science there? Llewellyn drew a line to systems theory: a team is a system. And it's a complex one. It's hard to isolate just one part, or to quote Dan North "What is the sound of one clapping hand?".
Starting anything in a system is like lighting a camp fire. In a team of solo programmers, even great ones, when one is stuck, he or she is (mostly) alone and stays stuck. For an idea to grow, one needs twigs, lots of twigs. And that's what mobbing is about: having a lot of people trying to enhance a given spark. To use a different metaphor Llewellyn said, it's exactly the opposite of a House M.D. episode (or the last episode of Silicon Valley season 1): one has an epiphany, or triggered an idea, and the rest of the team contributes to make it a better one. This impact is similar with memory and group memory. Group memory is better than one mind, and the mob can trigger multi-memory. It's the same thing with problem solving: you have a system state encouraging what Takeuchi and Nonaka called "diversity". And diversity is useful when things go south.
Llewellyn asked the following, apparently simple question:
How do you build a team?
There are two prerequisites to his answer:
· In a mob, you do not know where the ideas come from, and indeed that's not the point. On the contrary, most of the time we suffer from the survivorship bias: one's looking at the thing that brings success where you should reverse the analysis. For instance, usually, senior executives are said to have better ideas, because their ideas are used. However, most of the time this has nothing to do with the idea by itself, especially in a meeting. It's all about HiPPO: when the senior is talking to and not working with the team, the mechanism of success is different. To put it bluntly, when the project is a success, it's thanks to the Senior's idea; otherwise is because of the team.
· This leads to one other effect Llewellyn explained: the Benjamin Franklin effect. When we think we are kind, considerate and respectful with people, it's the opposite: it's the people you are kind, considerate & respectful with that you like.
So the full answer to the simple question is:
Working together as a team. [...] You are the sum of the people you hang with
This is where we go back to humanism: if a team is more than the sum of the people, and we are the sum of the people we hang with, we must be kind, considerate and respectful. This is where the Lean principle of leading by example comes into effect.
The last point Llewellyn tackled was the difference between Technical Debt & Technical Assets. Thinking only about liabilities and forgetting assets is unfair (and quite easy when you're looking for cost reduction and not value creation).
The myth of the 10x developer is a hard one to kill. But what does of 10x developer look like? With some example based on maths I do not understand much, Llewellyn's conclusion is that usually 10x doesn't look like what you are expecting. It's a matter of perspective, and 10x faster could look slow but can be super effective.
To make this point more concrete, he introduced a difference between two strange concepts:
- Infinite task, for instance cutting a cake in two till the end of time.
- Super task, which is basically an Infinite task with a time limit. Cut a cake in two in two minutes, and the remaining part in half that time. You'll finish to cut the cake in less than two minutes.
From this point, and to go back to an Exec perspective, no one can say what it's like to invest 1% of someone's time in learning. On the other hand, if you're working in a big (or maybe old) company, there is a chance that you understand what it looks like not to learn for 10 years!
To conclude with mob programming, the main focus is culture: to achieve transformation, it should be one of openness and invitation. This is really a takeover of his talk as a mise en abyme: you should go to conference as a team, with this culture of openness and invitation. Otherwise when you come back with new concepts, the team is not in synch (and push you out most of the time).
