Some time ago I wrote about the use of metaphors in the field of software development (Metaphorically Speaking), and more recently on the risks of using colloquial English with international colleagues who learned business English (English for English Speakers). I’d like to revisit the subject, as I still see a lot of confusion out in the world, and we’re still coining new terms that strike people differently than intended.
Mobbing
One such new term is Mob Programming, or Mobbing. Coined in the United States by Woody Zuill, the practice of Mob Programming quickly became mainstream and is generally regarded as a very useful method of collaborative software development.
Only after Mob Programming had been in use for a while did Americans learn the word “mobbing” has a negative connotation in German. The English word “mobbing” has been adopted in the German language to mean “bullying.” The implication is a group of people are picking on someone. That’s quite different from the intended meaning in the context of software development.
A possible workaround: Substitute a German word when working with German people. We might say, for instance, Zusammenarbeit. It’s accurate, but more general than “Mob Programming,” which has a specific routine involving “driver” and “navigator” roles, and isn’t just generic collaboration. So, something is lost in translation.
We don’t want to offend people, or turn them away from a useful practice because its name is questionable. The noted Finnish software engineer and writer/speaker, Maaret Pyhäjärvi, and the Canadian software engineer Denise Yu, suggested we use the word ensemble in place of mobbing (Five Years of Mob Testing, Hello to Ensemble Testing).
The word ensemble resonated with many of us. It doesn’t imply anything specific about the driver and navigator roles, but it does seem to capture the essense in a way that feels natural; in a musical ensemble, for instance, the players listen to each other and “feel” the music in a way that leads them to play cohesively and consistently.
You can see this happening when you watch this video of jazz trio Philippe Saisse, Armand Sabal-Lecco, and Senri Kawaguchi: “Wupatki” at Triangle Live, Japan 2018. The musical experience is a product of the three of them playing as an ensemble, and would not be reproduced by any of them alone, or in any other combination of musicians, or by the same three musicians on a different occasion. Ensemble felt to me like a metaphor that worked well.
Are musical metaphors useful?
I say “you can see this happening,” but can you? Maybe you can and maybe you can’t. I shouldn’t assume the metaphor is meaningful to everyone. The truth is I have no idea what a non-musician hears when they listen to music. I don’t think it’s the same as a musician hears, because formal musical training from a young age alters the physical structure of the brain. It might be something like color-blindness. That would make musical metaphors useless for a general audience.
I started to read and hear objections to the metaphor, ensemble. Software developers who are not also musicians had difficulty relating to the term. To them, “ensemble” implied nothing at all. They actually preferred to say “mobbing” because it made sense to them. They would ask their German colleagues to remember the context and try not to be put off by the word.
This caused me to stop and think. I had been using musical metaphors in my coaching without considering whether the people I was working with could relate to them. For instance, I sometimes say that practicing code katas is like practicing scales on an instrument. But what could that possibly mean to a person who has never picked up an instrument? Would they think of fish scales, maybe, or scales for weighing things, or dentistry?
Another favorite of mine that I need to re-think: A long-term process of improvement can be summarized by Clark Terry’s mantra, “Imitate, assimilate, innovate.” A novice “agile” team or a software engineer new to certain technical practices might begin by imitating what others do, like a student musician copying a solo of Charlie Parker from a record. With continued mindful practice, the student begins to assimilate what Parker is doing on a deeper level, and to incorporate that learning into his/her own playing. Eventually, some musicians may reach a level that they extend the art – they innovate. In our field, this is equivalent to a person like Ward Cunningham, Kent Beck, or Martin Fowler. Most people never reach that level, and that’s okay.
So, is a musical metaphor helpful? Maybe it only resonates with people who happen to be musicians as well as software engineers. Can we find metaphors that “work” more generally?
Are martial arts metaphors useful?
A popular metaphor for learning, at least in the “agile” community, has been shu-ha-ri. The metaphor came into the “agile” community via Aikido, but the concept has a longer history and broader application than that. As far as I know (and I’m no expert), the idea comes from Japanese traditional arts, where it’s known as jo-ha-kyu (序破急), or “beginning, break, rapid.” The general idea is that actions should begin slowly, gain speed, and end quickly. It applies to everything from tea ceremonies to Noh theater performance. This is pretty different from what we mean when we use the shu-ha-ri metaphor in the context of software work. We usually mean it in a way similar to Clark Terry’s imitate, assimilate, innovate.
According to Wikipedia (which is never wrong), Aikido master Endo Seishiro said, “It is known that, when we learn or train in something, we pass through the stages of shu, ha, and ri. These stages are explained as follows. In shu, we repeat the forms and discipline ourselves so that our bodies absorb the forms that our forebears created. We remain faithful to these forms with no deviation. Next, in the stage of ha, once we have disciplined ourselves to acquire the forms and movements, we make innovations. In this process the forms may be broken and discarded. Finally, in ri, we completely depart from the forms, open the door to creative technique, and arrive in a place where we act in accordance with what our heart/mind desires, unhindered while not overstepping laws.”
On the surface, this makes a lot of sense for people who are starting to learn about “agile” methods, or anyone who is learning a new skill. The Eastern philosophical flavor of shu-ha-ri appeals to Western “agile” trainers and coaches who tend to to think they are introducing some sort of mystical philosophy (mindset, culture, blah blah), although the authors of the Agile Manifesto were quite grounded in practical concerns – what “works” vs. what “doesn’t work.” But as appealing as it may be, I’ve seen problems with using this metaphor in the field.
The problem is that very few “agile” trainers and coaches practice martial arts, and neither do most of the people trying to learn from them. They understand the metaphor only on a very superficial level. When learners press them for a deeper explanation, they are at a loss. Their reactions often cause learners to lose confidence in them. They give the impression they have memorized some fine-sounding words that have no substance behind them.
If you, yourself, practice martial arts or music, then you may be able to use metaphors from these fields effectively; but even then, their effectiveness will depend in part on your audience. It’s good to be aware of that and adjust accordingly.
But sports metaphors ought to be pretty safe. After all, everyone enjoys sports and is knowledgeable about them, right?
Are sports metaphors useful?
Probably the best-known sports metaphor in the software field is the product development management framework called Scrum. It’s explicitly based on the sport of Rugby. I’ve mentioned this before, but for me the metaphor didn’t “work.” When I was first learning about Scrum (the process framework), people used terms from Rugby (the sport) as if they assumed they were explaining things clearly. But I had to learn a little bit about Rugby before I could understand the metaphors people were using to explain Scrum (the process framework). Instead of clarifying, the Rugby metaphor introduced yet another layer of abstraction I had to drill through.
When I mention this to Scrum trainers they almost invariably reply that Rugby is a global sport and “everyone” is familiar with it. This reflects a common problem among trainers and coaches, and maybe among humans generally: They assume their personal experience applies to everyone else.
Is Rugby something “everyone” can be expected to know? According to Total Sportek, Rugby is the 6th most popular sport in the world. They used 13 specific criteria to rank sports, including things like “global base and audience,” “TV rights deals,” and “average athlete salary in top league.” Their criteria reflect a certain way of looking at the question – total spectator interest and overall commercial value, normalized across the world.
And that’s the problem: The results are normalized across the world. Every sport isn’t equally well-known in every locale.
Soccer ranks #1, and basketball #2. It’s probably safe to say nearly everyone in the world knows at least something about those two sports. Next came Cricket, Tennis, Athletics, and then Rugby at #6.
Here’s the rub: The biggest markets in the world are the United States and China. Rugby isn’t much of a “thing” in those countries. So choosing Rugby as the metaphor for the Scrum framework reflects a bias – the assumption that “everyone” relates to Rugby. Everyone doesn’t.
Ostensibly, a core idea of the Scrum framework is the cross-functional team, in which each piece of work can be handled by a person who has the requisite knowledge and skill. The metaphor is related to the way a Rugby team moves the ball down the field, handing it off who whichever player is in the best position to move it forward.
You could as easily relate this to Athletics – a relay race, in particular. I suspect more people worldwide would relate to that metaphor than to Rugby.
You could move higher on the list, to #3 – Cricket. The problem there is that it may rank #3 according to the criteria in this ranking, but it isn’t well known in the two largest markets.
What about #2 – Basketball? This sport is spread more evenly around the world than Soccer or Cricket, and it offers the same sort of teamwork metaphor as Rugby. It may have been a better choice as a metaphor for a product development process framework.
The Total Sportek ranking focuses on spectator sports that are commercially successful. Coaches often use metaphors from participation sports and games, as well. I know one who likes to talk about “calling your shots.” It seems to be a reference to billiards or pool, in which you might “call your shot” by saying, “eleven ball in the side pocket.” He’s referring to things like estimation and delivery commitments. But everyone doesn’t play billiards, even recreationally.
The same issue applies to a phrase like “tee up the ball,” which (I think) refers to golf. He may have been referring to something like a sprint planning session in Scrum, or a replenishment meeting in Kanban. I don’t golf, so I can’t be entirely sure. As I understand it, the procedure is to put the ball on top of a little stick so that you can hit it with a bigger stick. I understand it in the general sense of “getting ready to start,” but that is not a deep understanding. For me, it would actually be easier to understand “sprint planning session” or “replenishment meeting.”
Are metaphors useful?
I’ve found people are pretty familiar with the organizational constraints and other issues affecting their work. They usually have some sort of goal in mind when they engage an outside helper. I like to learn what their goals and pain points are, and describe practical ways to close the gap between the current state and their goals using language that directly refers to the situation. Metaphors seem to get in the way more often than they help.