I recently hosted a Magic-the-Gathering-themed tween party for 8 players.
Yes, you read that correctly. 8 players in a format I later learned is called Free-for-All (a.k.a. Circle). Little did I know that most MTG games were smaller, with an “epic” game being maybe 6 players… 🤦
While my husband did some excellent turn-based coaching for the new players – about half of the assembled – I noticed something essential was wrong. The kids were disengaged from the game unless it was their turn to play. Considering they’ve been rabid Pokémon fans, I couldn’t understand how they could completely check-out from a “grown up” monster beatdown game…
Then it dawned on me: the turn rotation was too long. The kids had enough time between turns to be restless from the sugaring-up and general high energy of being together outside of school.
This distraction is the same issue that I’ve seen with attempts at mob programming!
For any reasonably sized team (let’s assume <= “2 pizzas”) trying to mob program, short turns are essential. In fact, I’m not sure that group size figures into the turn duration calculation – short turns are just better!
How long is too long? For me, 15 minutes! Bias yourself to less than 10 minutes, preferably 2-5 minute turns. I’m aware that at-a-glance this feels absurd, but let me explain.
The basics of mob programming are 3+ people programming together at a single computer with 1 person directing the current activity, 1 person hands-on executing the current activity, and 1 person observing/commenting/contributing from the “mob” crowd seated around the computer. (In some descriptions, the “mob” may also be considered as part of directing the activity, but 1 person makes the decision about what to do/try next, so I prefer to differentiate between these roles.) Unlike strong-style paired programming, these roles are insufficient to be mob programming: for a mob, you must also have rotation!
As “circus performers” (a.k.a. mob programming facilitators) for Bryan & Bill’s Three-Ring Design Circus at deliver:Agile 2018, my pair Tim Ottinger and I instituted a 5 minute rotation schedule for our mob of conference session attendees (read: strangers). Our task was test-driven development (TDD) and refactoring of a sample programming project.
Short rotations encouraged:
- low barrier-to-entry experimentation with TDD and mobbing
- selecting and trying an idea quickly
- refining communication patterns
- collective ownership of goals
- fast feedback
Tim and I were a bit more merciful with our 5 minute rotations in that we encouraged participants to continue the execution of the previous driver where another “circus performer” insisted on a fresh start (read: deleting code) when TDD automation wasn’t passing/green at the end of a 2 minute rotation (the hard-core strategy of one of our other performers). So much excitement!
In the workplace, over the years, I have participated in pseudo-mobs wherein a single programmer or a pair of programmers consult another team member on particularly challenging aspect of a programming problem. Often, this results in another programming team member chiming in with insight or advice and now we have an amorphous gathering around a single programming work station where the work is being implemented. This is even more likely when the consulted team member is also paired programming (i.e. 2+ pairs collaborating on a complex issue in the code).
While pseudo-mobs definitely help with resolving an issue, we miss out on some of the benefits of the mob structure:
- explicit statements of intent through navigator-driver pattern
- everyone having hands-on time implementing a solution
- everyone directly participating in the decision-making and experimentation
- single piece flow / avoiding merge conflicts (since only 1 unit of work in-progress)
- novice or new team members developing shared understanding and receiving training opportunities from the explicit exchange of multiple points of view and potential solutions
Now back to the Magic game! Upon reflection, how would I have changed the game play to optimize for faster turns/better rotation?
The common wisdom seems to be smaller groups for quicker decision-making and turn progression, e.g. 2 player (1v1) games or team play (e.g. 2-headed giant, emperor).
I could also imagine a simplification of rules for younger/newer players to lower the barrier to entry…
- Maybe removing the complexity of the “advanced topics”
- Constructing “beginner” decks without cards that have complex abilities/rules
- Visible structure or cues, e.g. instructional playmats for easy reference along the way
Upon further investigation, I discovered a co-operative format for MTG: Horde Magic!
All the players form a group working to defeat an automated “horde” deck. The team members all take their turn together to attack and block. (This reminds me a lot of the mob programming format with a product team assembled to “defeat” a difficult software problem.)
In Horde Magic, if some aspect of game-play isn’t fun or isn’t working well within the rules, the team members come to a consensus as to what works best for them. (The mob can iterate on their working agreements as they work through the problem in order to work more effectively together.)
Given what I know so far, I’m looking forward to trying some new things, both at work and at play. Having a good mobbing experience takes a bit of planning and some skillful facilitation, but it’s the game for everyone!
