Understanding Mob Programming as a trivia team.
Going to the lake with friends for the weekend, we often play a game Friday or Saturday night. Poetry for Neanderthals, Secret Hitler, Codenames (my personal favorite). We had an original edition Trivial Pursuit, which was hilarious due to how outdated the questions were (1981). Trivial Pursuit can be a little slow with the dice and the board movement, so we invented a faster game, with a little psychology involved. With the box of cards only, every player gets one “question” card. You choose one of the 6 questions to ask the table. Anyone who believes they can answer puts their hand on the table. Now the questioner picks the person to answer (presumably you want to choose the person you think is least likely to know the answer). If the Answerer gets it right, they take this card as a prize; if they get the answer wrong, the Questioner takes their card as a prize. You want to ask questions that seem easy enough that several people will think they know the answer. It’s a fun variant, and plays quickly.
Trivia games are incredibly popular, probably half of TV game shows are trivia based, and almost everyone has been to a bar “Trivia Night”. I’m sure it rivals karaoke as a fun activity people can play with strangers, with no prior setup established. As we played our trivia game over the weekend, I thought about the trivia night teams I’ve been on, and the fun we had. I’m a pretty strong trivia player, if I can brag… I have a huge breadth of knowledge across many subjects, except sports. And thus lies the key element to assembling a winning trivia team. You want a variety of friends that cover the full range of potential topics: music, television, and movies; fashion and pop-culture; books; science; sports, etc.
It occurred to me, “trivia night” is a perfect analog for Mob Programming, and helps explain why Mob Programming works. Suddenly images formed in my head, combining all the concepts I frequently teach from Operations Management (OM) science, Scrum, Agile, XP, McGregor’s employee motivation Theory X and Theory Y, traditional project management, and Mobbing.
The longer I’ve thought about OM, the more I’ve focused on the Venn diagram depicting Physical Manufacturing, Customer Software Development, and the area of overlap between them. There are certain OM concepts that only work in physical manufacturing, and they largely take advantage of the rote repetition of an assembly process that is known with 100% certainty. This is the advantage you use to squeeze every last ounce of efficiency from the production; repetition of the exact same thing, with the same timing, same optimized sequence, same parts, same manual labor steps, same everything, every time. In factories, we can do Value Stream Mapping, and calculate the exact optimal sequence, timing, buffer inventory— and that will continue to be advantageous as long we we keep the same production line. The longer we run that production, the more we stretch out the apportioned value of the up-front costs we incurred in determining the setup. Factories are largely a “Theory X” world, where no one wants to sweat all day wearing a hard hat and steel-toed boots, stamping the same metal part all day long. The management assumptions revolve around rewarding people for doing something they are reluctant to engage in.
Some aspects of manufacturing can be taken exactly as is, whatever elements overlap with custom software development. In other cases, we can use the basic heuristics of factory science, even if we can’t use the specifics. But largely, custom software development is fundamentally different than repetitive manufacturing.
In custom software development, in theory
every problem is being solved for the first time.
Every “piece” of work is a novel problem. If our software already did what’s being asked, there would be no request; if we could easily copy and paste the code from another project, we would do that; if it’s easily solved with off-the-shelf software, or a 3rd party vendor product, framework, or component, then we use that. Custom software development is by definition, uniquely novel at every turn. And at each point while you’re developing a solution, the only thing that matters is the precise technical obstacle you’re facing right that second.
As this is running through my head (and I’m losing track of the game I’m playing) I start seeing a factory, and traditional project management as a long tube, with a series of sequential, individual jets pushing items through the pipe. In far too many companies, we are still managing fascinating and unique custom software development as if it were the dull repetition of bored workers needing a carrot and stick reward system.
But in the regime of the constantly novel, we are in the opposite of luxurious certainty, linearity, repetition. Every feature is a puzzle, every step is an unknown. We can’t break the work down and do it sequentially due to the uncertainty, which shows up in repetitive loops during the process. Every step is a question. Every step is a question. Every step of the process in developing a software solution is literally one question being asked of someone, one at a time, and only the one question matters. Like trivia night!
When you are in a team playing bar trivia, no one knows what the next question is going to be. You can’t estimate it. No one even knows what the categories might be; or if the hosts have categories, and if so whether they do them sequentially, or ask one question per category in each round. Will they ask one question at a time, or will you write down and turn in many answers per round. Is this trivia night Halloween themed because it’s October? Maybe scary movies are on the menu. No one knows. You can’t prepare for it.
You can’t “divide and conquer”. Imagine if you only allowed your designated “Sports” person to answer the sports question. While sports is my weakest area, I’ve scored for my team when I knew the answer to some very obscure questions that I hadn’t learned because of anything sports related. If you divide your trivia team by topic, you lose all the benefits of the combined knowledge of the whole team at the moment of each question.
“But this is so many people on one task, shouldn’t we split up?”
NO. When you divide a team, you divide in-half, the probability that the team will be able to answer any given question. We have to ask ourselves, “What are we trying to accomplish? Everyone being busy, or flow of valuable code?”
It doesn’t matter if everyone is occupied with busy work, if nothing is moving forward. We should focus on one thing at a time, because the uncertainty and complexity of custom software obviates all the efficiencies that work in a known, repeatable environment.
Unlike our factory pipe with a series of jets (where one jet is each person or technical skill required in a “waterfall” setup), our trivia game is like one single opening, where one object appears at a time, and all of the jets are pointing at the object in the process. All of the force hits one object at one time, with maximum combined power.
The only remaining element in custom software development is managing the decomposition, queuing, and priority of items to put in front of the combined power of the team’s jets. This is often the Product Owner role in a Scrum setting, but could be the customer, or collaboration of the team as well. Breaking the work down into the smallest granular piece is part of this process. In some trivia nights, the big question at the end might be six parts, and you have to get all six right— often with a chance to wager some amount of your points. If you miss one part, you lose everything. The constant temptation to batch software in many dimensions creates these same “all or nothing” risks, which often become a cost measured in long delays. Better to have six individual questions, where you might have a good chance of knowing four or five of the answers. In a software/customer context, you might “win” by just providing the first 20% of valuable features the customer asks for— which are likely to account for 80% of their need.
While Mobbing, we even get an advantage that brings us back to a heuristic from the factory model. Learning within the team doesn’t often help with trivia night. But it benefits everyone all the time in Mob Programming! You likely won’t hear the same trivia question on a future night, but how many times will you need to extract a complicated method to it’s own class? Once the junior developers on the team see that pattern a few times, as the Driver, later as the Navigator, they will be able to repeat it in the future, and recognize whenever that same pattern of problems arises. Heuristics!
“Theory Y” work with “Theory Y” workers should be fun.
Whenever I’ve been involved in a programming mob, it has been a fun experience. Especially since learning the formal (but still very flexible) method proposed by Woody Zuill and the guys at The Mob Mentality Show podcast. I see “coders” learning DevOps pipelines. Heck, even I’m learning DevOps pipelines. Database experts can see how the sausage is made in the code. I continually hear some version of “I didn’t know that hotkey existed”, “I didn’t know this was a problem for you guys, I can just make this JSON output all the time if it’s convenient”, “Now I understand why the data is getting out of sync”.
Trivia night with your trivia team is fun. You’re doing a social activity, you’re collaborating in real time, you’re building something that is more powerful than the knowledge of each individual. Programming as a team can be just as fun. And it brings the additional benefit of re-using the information shared within the activity.
Rather than practice factory mentality drudgery, weakly pushing one item at a time through the process; try doing something where all your team’s jets are boosting one item at a time through the single opening in the system. You’ll be amazed at how fast the work can go, how early you can complete features, how much you learn.
And you might have a lot of fun.
The Agile Couch 