When I was a kid, maybe eight years old, something magical happened to me. It was a sunny day. My parents had put a sliding door in our dining room, which lit up the space in gold every summer afternoon. That particular day, the room held my dad and a couple of his students from the high school where he taught Latin. They were limned in bright solar rays, excitedly talking about fighting goblins, looting gold, and casting spells while drinking Coca-Cola and rolling dice, having a grand old time.

Dad was the sponsor for his school’s wargaming club (later renamed to the ‘conflict simulation group’ at the behest of anxious administrators). Occasionally, his students would come to our house to play Dungeons and Dragons on the weekend. There was no satanic panic about the world’s most popular roleplaying game in our home. While my mother and my sister didn’t understand it (and still don’t), my father had caught the bug. He was happy to set up a space to play for the kids who could pay the toll to get across the Delaware River and drive the ten miles to our place.

I tottered in amongst the older kids, big as Hill Giants to me, and tugged at my dad’s sleeve. He looked down through his brown, plastic-framed Coke bottle glasses at me with a smile that was so rarely displayed to kids my age. I asked what was going on.

“We’re playing a game,” he told me.

I could tell he was anxious to get back to it, but I followed up with the obvious question: “Can I play?”

Dad laughed and told me no, I couldn’t. It was a bummer for sure, and he must have seen it in my face because he followed up quickly:

“Come back when you’re older.”

“How old?” I asked. I probably tried to hide my excitement and failed (something I still do poorly).

“I’d say twelve. Twelve?” He looked up at the other kids. I don’t think they were paying any attention, but I was. Because, even for a kid who struggled to pay attention to anything, this I would remember. Because this looked like so much fun.

Neither dad nor I knew that he’d be setting me up for not just the hobby that would define how I spent a large swathe of my recreational time moving forward, but also my experience with Scrum.

Photo by Clint Bustrillos on Unsplash

Ain’t No D&D Party Like an Agile D&D Party

I could tell you all about my time growing up in the hobby of tabletop roleplaying games (TTRPGs for short) – but this is not a gaming article. Instead, I’m writing about business. I’m supposed to write about goals. And, and, and… numbers. About making hard decisions and leading teams. We’re talking about planning for success and delivering products and value week after week.

And… figh… fighting goblins?

Well, as a life-long gamer, I can tell you that you will be amazed at how much Dungeons and Dragons can prepare you for business. Even more remarkably, how being the Emcee of a D&D game – a Dungeon Master – will prepare you for being a Scrum Master. 

Stay with me. I think you’re going to be very surprised.

The Basics of D&D

Before we get too far into the overlaps of Scrum Mastering and Dungeon Mastering, let me bring you in on what D&D (and any TTRPG in general) is, in case you’re in the dark.

D&D is a storytelling game where you and a group of friends take on the roles of adventurers in an elaborate fantasy world of swords and sorcery. These adventurers go on quests like defeating mad wizards or carrying out elaborate heists against tyrannical nobles. Players describe what those adventurers do in the world. A roll of the die determines anything that could be left up to chance (usually using a twenty-sided die or D20). One of the player’s jobs – the Dungeon Master (or DM) – is to set the stage and describe the world to the other players. The DM also takes on the roles of the supporting cast in the story, arbitrates (or throws out) rules where needed, and ensures everyone has a good time.

If it sounds like the DM has a challenging job, you are correct! I speak from experience here – I have been a DM for over thirty years across dozens of different campaigns and rules systems (D&D may be the World’s Most Popular Roleplaying Game, but it’s not the only one).

If it sounds like there are some similarities between the Scrum Master and the Dungeon Master, you are also correct. The similarities don’t stop at just the DM, though, so before we get too far into the similarities of DMs and Scrum Masters, let’s get down to some D&D brass tacks first. I promise not to get too nerdy on you.

Photo by S L on Unsplash

Scrum, Meet Party

Let’s talk about how a game of D&D looks through the prism of Agile (which I’ll refer to as Scrum World). Of course, D&D and Scrum World aren’t precisely one-to-one, so there are some things to map out for the sake of clarity:

• The Scrum Team maps to what in D&D is called a “Party”. 
• A Party typically comprises one DM and three to six Player Characters (PCs). The goal of the Party is usually to complete a story. The story can vary in length, but any given story will at least take several sessions, with an average session lasting two to four hours.
• In this analogy, the DM is a Scrum Master (and, if I’m being honest, a Product Owner between sessions). The PCs are Developers.
• The story is the product. The product’s Definition of Done is that everyone felt included, the story resolved to their satisfaction, and that everyone had a good time. To Quote master storyteller Neil Gaiman (@neilhimself): “It’s that simple, and it’s that hard.”
• A session is equal to a Sprint.

Learn more about Scrum basics in our online short course, Scrum Foundations

Scrum Master, Meet Dungeon Master

So, how are the roles similar? Let us enumerate the ways.

The DM’s Job is to Continually Deliver Value Every Session

At Agile’s core is the principle of continuing to deliver a quality, functional product at the end of every sprint. The DM’s job is no different. If the DM fails, the PCs leave. The party gets together every week to play D&D because they want to tell a story that engages and excites them. If the DM can’t do that, those PCs can do other things with those two to four hours per week, especially when those players are Busy Adults With Many Things To Do. They can get together to play a board game or watch a movie without the pretense of also having to pretend to be a Druid if they’re not feeling it. So the DM has to deliver.

The DM’s product, the story, develops like any Scrum team’s product: action by action and scene by scene over several sessions, just like products are assembled over a series of Sprints. Software code is developed line by line; cars are engineered component by component; devices are tooled part by part. And as each Sprint rolls out, the output should get better and develop into something closer to that big beautiful idea everyone was dreaming of at the outset. As the collective project grows, it gets better, and the DM or Scrum Master makes those little subtle nudges that bring out the best of the project. This brings us to…

A Good DM Identifies the Strengths and Weaknesses of Their Players

The DM has to learn a lot about each PC around the table to put them in the right places at the appropriate times. For example, they know that bringing a Wizard to a knife fight is a bad idea (at least at a low level), in the same way that sending a Fighter to a diplomatic assembly of Archmages is a classic faux pas. 

Photo by Artem Maltsev on Unsplash

To be fair, a DM has an advantage that a Scrum Master doesn’t: narrative control. DMs can mold a story around the players that come to their table. But, more often than not, a Scrum Master already has the right people around them if an HR department has done their due diligence. But not all team members will be the same, and those little differences matter. Find out who your Rogues and Bards are (and let them be POs, those interpersonal skills are excellent for stakeholders). Identify Wizards and Sorcerers early (and give them caffeine judiciously). Use each person’s skills and talents and let them shine where they’ll do the most good.

A Surprising Amount of the DMs Job Is Tracking Metrics and KPIs

Ask any game fan about its nuts and bolts, and you’ll quickly discover that many numbers are spinning around. Look at pro baseball. All you have to do is flip over a baseball card – stats galore. You can argue about whether or not some of those stats indicate anything, but metrics count to stakeholders, and they hold you accountable to them. To the stakeholders of those pro sports teams, those stats are all Key Performance Indicators (KPIs), and if they dip too far, it’s back to the minors for those players or even farewell from the franchise entirely.

In D&D, it’s different, of course. PCs have a Character Sheet that lists all the things they can do in an even more concrete and non-debatable sense. Most relevant details are listed on that sheet, from how strong or fast they are to how well they take hits to how many spells they can learn and cast in a day.

Fail to keep your party’s KPIs up to snuff, and your PCs could find themselves tapped out of many encounters. Worse still, they could be overpowered more permanently at the end of some nasty critter’s claws. Well, on paper at least (if a character dies, they can always roll up another one or pay a cleric to resurrect them, c’est la vie). But, players are encouraged by an excellent DM to make sure that they keep their PCs moving toward their goals in a way that keeps the story enjoyable for everyone, and that means knowing how to set realistic goals based on capability. 

A good DM must know what a PC party can realistically handle in any given situation and set tasks accordingly. They best track that by the Party’s KPIs, which for a PC could be anything from their Armor Class, Damage Per Round, or the number of Spell Slots they have. Scrum World examples will vary, of course, based on the given Devs outputs. But, it maps in more similar ways than you’d think. Speaking of challenges…

A Wise DM Encourages Innovative Solutions (and Gets Failures Out of the Way Early)

A good DM also knows that they often have to put their players in positions where they might just fail. Failure is a part of the game, and it’s why dice are involved.

Any time there’s a chance something could go wrong, the DM calls for PCs to roll a die. The die result checks against a difficulty set by the DM. An easy D&D task is usually a 10, while something nearly impossible is a 30, with most tasks falling somewhere in the middle. And sometimes, even a high-level character rolls a one and botches at something in which they’re skilled.

It just happens. It’s going to happen to your developers in Scrum World, too. As both an experienced DM and a newly-minted Scrum Master, I’ve found that the earlier you can get that kind of thing out of the way, the better.

Case in point: a player in one of my parties had designed their PC as a healer. He chose to play a Cleric, a role traditionally suited to this (not always the case in fifth edition D&D, but that’s a whole other blog article for an entirely different place). When the first battle came around, he decided on the first round to surprise everyone. He waded into the fight and hit the bad guys with his staff. The Party took a beating with their healer tangled up in the melee. They survived though, albeit with more dings and scratches than they signed on for.

To their credit, no one in the Party got upset, but I held an impromptu Retrospective after the session. The big question was: why did the Cleric go in running? The answer was that he simply wanted to be helpful in the moment. The Cleric happened to roll high on his initiative, meaning he went first. No one was hurt yet, and he didn’t want to waste a turn, not thinking about holding his action instead of rushing in.

From that point forward, he knew waiting for the team to move in before committing to any actions was an option, making for a better strategy as a support member of the party. If things went well next time, sure: he could clobber some opponents. But, if he was going to shine as a healer, he might want to hold back no matter how good his initiative rolls were to see if a teammate needed support before going on the offensive.

Photo by lilartsy on Pexels.

A Smart DM Encourages Multiclassing

There is a school of thought among PCs in D&D Parties that staying in your lane is best. You should Know Your Role (in all capital letters) and never leave it. A Rogue should stick only to situations where they pick locks and can benefit from providing sneak attacks. A Warlock should always be in the back and cast Eldritch Blast on repeat into infinity. A Wizard should cast Magic Missile until they’re out of spell slots and then hide under a wagon until the fighting is over. 

It sounds reasonable. Players pick these roles because they want to be good at certain things. And those epic, level twenty powers sound cool. Who doesn’t want to max out a class and be the Thiefiest Thief to ever Thief?

I have a secret for you. Lean in close. I will lay some expert DM knowledge on you from my thirty-plus years of experience.

You’re never going to make it to level twenty. I have no intention of letting it go that far. Not in my campaign, at least.

Every D&D game I have ever run has either fallen apart or come to a close well before getting to that stupidly high-level threshold. The highest I’ve ever gotten as of this writing was a tenth-level Party. That campaign had single-class adventurers fighting tooth and nail with low saving throws against conditions that, if they multiclassed, would not have been problematic at all.

Anyone used to working with Scrum will tell you about cross-functionality. Building it into a team is at the crux of agility. A good DM learns this quickly and encourages this in their party. A Barbarian that can clobber a sentry or sneak around them after putting a couple of levels into the Rogue class will be able to hold onto their rages for better use later. A Fighter who can cast a couple of Mage cantrips can get an edge in their encounters without risking their neck quite as often. And the saving throws get nothing but better. 

Scrum World Developers similarly get better when a Scrum Master pushes them to develop accordingly, setting them up for success with the right coaching techniques and skills. In Scrum World, technology and science advance too quickly to let team members focus on a single discipline. Overspecialization can set Devs and their Scrum teams up for obsolescence or single points of failure. Coaching new skills and pushing teams to adopt new technologies and methods will keep your team cross-functional in a fast-changing world.

The Best DMs Know Planning is Good, But Being Prepared is Better

As a DM, I have had an entire story fall apart after a player with a lucky roll took out my villain in a single hit. There was supposed to be a whole arc with that villain as a recurring character. He would keep the party on their toes week after week as a nefarious player in the shadows. Instead, a single die roll ended the whole thing thirty minutes into the first session. Everyone went home, and I was intensely frustrated. I had a plan I worked on for hours, but I wasn’t prepared for a player to pick out the ridiculously overpowered weapon used to kill my bad guy.

There is a difference between having a plan and being prepared. With a plan, you have already committed to a specific course of action. You put things in place, worked out fine details, and estimated the functions of all the moving parts. There are processes and documentation you probably reviewed. You counted on those things to work out exactly as planned and with little deviation.

An experienced DM knows better. PCs – who are ideally the DMs friends and sometimes their family – are only there to have fun. They do not give a damn about any of the DM’s plans. They have their own ideas about how fun happens during the session and it may have nothing to do with a DM’s plan. All a DM can do is know the PCs and prepare based on what they know about the Party. DMs need to have a lot of options available to them, know where they all are, and to only dive into the specifics once they are needed.

PC (and Devs, for that matter) will not be little copies of the DM and will not act the exact way you want. Nor should they. PCs and Devs are human, unique. They bring something to your Party or Scrum team through different ways and means. It’s not something to be beaten out of them or micromanaged. Humans, shared stories, and volatile industries fiercely resist being wrangled in such a fashion. 

To approach complicated and uncertain situations with agility, a good DM or Scrum Master should prepare to optimally use their PC’s and Dev’s unique approaches and methodologies. Then, find the right coaching approach to engage them. When a Scrum Master or a DM can engage their Party or a Scrum team, it’s amazing what they can do.

Photo by Charlie Solorzano on Pexels

As a DM, I must sometimes work hard to get in my players’ heads since I love bringing my favorite hobby to new players (new PCs haven’t learned how to be cynical PCs yet). Finding out how they approach the gaming table can be challenging. Do they like to fight, or do they like puzzles? Do they live for drama, or do they just want to help everyone around the table? Is the thrill of adventure something they live for? Or is it an excuse to cook for everyone around the table and see friends? Once I find what motivates them, I find the best way to run a game for that group… and then I can plan.

This Sounds Hard

It is hard—both the DM job and being a Scrum Master. Taking on either role takes serious determination and a lot of practice. But agile42 is here for you. The Scrum Master part, not the DM part! The good news is that everything here works in reverse, too. If you want to be a good DM, being a good Scrum Master is a great place to start! Book an appointment to speak with us at agile42 North America today to learn more about our coaching and training services. And, of course, go to DNDBeyond to learn more about Dungeons and Dragons, the World’s Most Popular Roleplaying Game.