top of page
Search
  • Writer's pictureTim Burns

D&D and Scrum - "Rules as Written"


The Author's setup from his Home Campaign


I'm an avid game master (dungeon master). I have run D&D tables at a local gaming shop and a home campaign that's been off and on since 2019. My interest in programming started in the early 80s when I was twelve. I enrolled in a Fortran class with my D&D best friend and wrote a program to store character stats. My first actual program was a dice roller on my Dad's HP 41c calculator.


In D&D, I have found that the best way to play is "Rules as Written." That means don't make up your own rules, and follow the books. The mechanics have been refined in a game that's been played since the 70s, and following those mechanics makes the game balanced and fun. I've been most successful as a DM when I let the game mechanics drive the plan and focus on creating a fun adventure for the players.


The same thing goes with Agile methodologies. I'm now a scrum master on a project and follow The Scrum Guide -- rules as written. Scrum is over ten years old, and the ideas behind Scrum are likely as old as D&D.


The guide only contains 14 pages, yet I constantly look into the manual to determine the best course of action. In sprint-after-sprint, my projects change, focus changes, and people join and leave the team. I often need to look back and examine specific wording in the guide to achieve the team goals. I never find myself in a situation where I can put scrum mastering on autopilot, set up recurring meetings, and go through a script. I find scrum mastering similar to DMing a new table week after week.


Here are some small tips that I use to keep my scrum mastering focused on the product:


One: Avoid setting up all the meetings on recurring autopilot. It's tempting to schedule all of the ceremonies on auto-repeat: The meeting list scrum, create the daily standup, a sprint planning meeting, a sprint review, and a retro at the end. In practice, however, if you schedule intentionally, you will ensure you have the right people, focus, and timing, and it keeps the sprint's focus on building an increment.


Two: Use tools to reduce the amount of work you need to do. Like my dice calculator and the character builder I wrote many years ago, Having good tools makes playing the game more straightforward and fun. I like to use TeamRetro for retrospectives. It reduces the emotional energy I need to put into the retro and makes it more likely I'll do it. Dropping the retrospective is one of the most common anti-patterns that Scrum teams have, and an excellent tool to make it easy-as-pie makes that less likely.


Three: Scrum defines the role of the Product Owner, and it is essential. The product owner is the "A" in the RACI matrix on a project plan. They are the sole accountable decision maker for the direction of the product. They must know the product well; in the same way, the Dungeon Master must understand the rules and the current adventure well. People will always join and leave the team, and the direction of the product needs to always be to the product. They have to know the product like the DM understands the fantasy world they create at the table.


So, that's my Sunday thought on Scrum and D&D. I'm glad I can be a nerd and relate two things that make my life more enjoyable on this blog.

18 views0 comments

Recent Posts

See All

Carto, Snowflake, and Data Management

A basic principle of data management: Don't move data unless you have to. Moving data is expensive and error-prone. Data Egress Cost: How To Take Back Control And Reduce Egress Charges Archiving to S

Comments


bottom of page