Training

Running a technical workshop as a D&D style adventure game

When I was invited to give a workshop at Agile Testing Days 2018 (Potsdam, Germany), I wanted to teach lessons in test advocacy and management because I think these are really important skills that can be difficult to learn effectively. I thought about how I learned these skills and it was always through experience rather than advice. I think that’s part of what makes it a difficult topic to teach. So I had a wacky idea – what if I got the class to try out the lessons learned by roleplaying, in a Dungeons & Dragons (D&D) style adventure game?

Then I had an even wackier idea – why not do THE WHOLE THING as a Dungeons & Dragons game?

After that, everything fell into place for me. I’ve been running D&D games as a DM (Dungeon Master) and writing my own campaigns for two years now so designing a workshop in a similar way felt very natural.

Why D&D?

Oh for so many reasons!

  1. It’s fun
  2. It’s pretend, so players can take risks that they wouldn’t necessarily take in real life
  3. If it’s done well, it *feels* real

This is all a perfect formula for a workshop. I wanted participants to not just learn what I taught them, but to feel like they had lived through it.

How to write a D&D campaign workshop

Writing a D&D game is not like writing a story book. It’s more like writing the rules for a theme park that your players will explore and interact with. So instead of thinking about what the players will do, it’s better to think about what situations you want the players to encounter, and the consequences of solving or not solving the problems presented.

I thought back to my real experiences working at large organisations as a test manager – what were the situations that led to the lessons I learned? What helped me to win and what caused me to fail? I did my best to simulate a similar environment for my workshop players.

I briefly thought of using a metaphor to guide players through a dungeon and relate it to a difficult workplace, but I thought it best to simulate as close to real life as possible. However, I did want to add a bit of that D&D “epic adventure” feel to it, so I set quests and a sense of urgency to add drama and excitement.

As a side note: I’m so happy with how my slides turned out. I designed them all myself using Canva and some graphic design tools and I think they look super slick.

Game mechanics

Then there were the mechanics to consider. I didn’t want my players to be killing everyone in their organisation – it’s neither realistic nor a lesson I wish to teach! However D&D is much more than combat anyway – primarily it is a way to explore a world in our collective imaginations. So combat was just discarded. The mechanics needed to be simple, so that anybody could play the game right away, even if they’d never played D&D before.

I settled on these rules:

  • Roll a skill check:
    Roll a d20 (20-sided die). Add that number to the skill value on your character sheet. That’s your score. The DM will tell you whether that result means that you passed or failed.
  • If you roll a 20.
    That’s called a “natural 20”. You automatically pass with flying colours!
  • If you roll a 1.
    That’s called a “natural 1”. You fail catastrophically!

There’s a concept in D&D called “Difficulty Class” (DC) which is a number that the DM knows that the players have to beat in order to succeed at a skill check. For example, if the players want to test an app then that is a testing skill check. They might roll a 10, and add their testing skill value of 5, bringing them to a total of 15. Is that enough to successfully test the app? Well, that depends on the DC. If it’s a fairly simple app and easy to test, I might set the DC to 10. A 15 beats that so they would have successfully tested the app. But if it’s a really complex app and very difficult to test I might set the DC to 20! In that case, a 15 would not be good enough and the player would fail to test that app effectively.

The advantage of not sharing this number with the players is that it gives a bit of power back to the DM – I can fudge the result if I really need the group to go a certain direction in the story. However, there’s still a chance of natural 20’s and 1’s so it still doesn’t give me ultimate control!

I am a big believer in letting the story go where the players lead it, regardless of how far that takes them off the main path I designed. This lets the players really feel like anything is possible, and encourages more creativity which is something I love to see in a D&D group. However, in a workshop setting I also need to be mindful of time and make sure that we’re actually covering the lesson materials so that my attendees get value from my course! So I designed these mechanics with this balance in mind.

However, one thing I did as a workshop trainer that I would never usually do as a DM is to review at the end of each quarter and try to explain lessons to them as a result of what they’d done so far. This had the effect of keeping them on track with the course materials, as well as making sure there were opportunities for learning even if the group was getting sidetracked in the game.

Everyone is Alex

The biggest challenge was managing a group of 13 players who were all there for the experience of being a test manager. Typical D&D games run with a group of 4-6 players. More than that becomes a bit difficult to manage. I was worried that not every attendee would have a chance to play the game, and only one of them would be able to experience being the hero.

I did a bit of research and there’s a game called “Everyone is John” where every player plays the same character. One player gets to control John, and the others are voices in John’s head vying for control. They gain control with successful dice rolls. I decided to use this idea but to give everyone an equal chance I let everyone take control of the main character (Alex) for 15 minutes each (I know it says 10 in the slide – I changed my mind). That person would be the decision maker. Everyone else could suggest things but that person had the final say on what the main character would do. That person was also in charge of dice rolls.

Even with this game mechanic, I still didn’t feel like the format would fit a group much bigger than 10. I optimistically capped the attendee limit at 12.

Setting it up

I divided the game into four parts, each part representing one quarter of the business year. Each quarter had a theme and a major lesson to be learned.

I handed out the same character sheets to every player – Alex (main protagonist), and two team members. Each player also received an organisational chart. The character sheets listed a description of the character, a list of skills and their values, any current quests, and some items in an inventory.

Each table had a collection of silly hats. The rule was that whoever was the main character had to wear a silly hat for the 15 minutes that they were in charge of Alex. That showed everyone who was in charge, and I hope also reminded the players not to take it too seriously and try some risky things that they may not ordinarily try in their real workplace.

On an overhead projector I showed slides representing non-player characters that they encountered during the game. I had three decks – a main set of slides for the main story, an NPC deck for every character in the game, and an encounter deck for random encounters. It was pretty easy for me to switch among these depending on where the game took us.

There was a big flip chart for us to write on, which ended up becoming very important.

How it went

It was awesome. It sold out!

Right from the start, the group was really engaged and involved with the story. There were naturally some louder voices in the room, but rotating the decision maker meant that everybody got a turn to have a say. Even if the louder folks were still suggesting things during someone else’s turn, sometimes when I deferred back to the decision maker they would just say “No. We’re doing it this way.” and that would be that! It was great to see this happening in such a large group.

The situations were familiar enough that the group was able to understand them, but the problems were different enough that the group still had to think hard about them. I tried to make consequences as realistic as possible, drawing on my own breadth of experiences.

One thing that really took me by surprise was the sheer amount of natural 20’s that were rolled. In two years of playing D&D I have never seen so many natural 20’s. But hey, you have to respect the roll! So at one point in the game the group managed to implement a whole CI system in an afternoon. :)

The dice rolls really added a sense of chance and excitement to the game. There were gasps and cheers when the d20 results were rolled. It was awesome to see everyone so emotionally invested in the gameplay.

Another great sign was that the group was still discussing how to solve the problems when lunch was called, to the point where I had to shoo them out of the room and remind them to eat!

At the end we wrapped up by reflecting on the lessons learned. What was interesting for me as a trainer was that by simulating these experiences, they learned even more lessons than I intended because there were lessons in those experiences that I’d forgotten were there.

Some of the lessons learned were:

  • How to show design a good presentation
  • Measure things
  • How to assign testers to teams
  • Productivity = reducing waste
  • How to enable and empower people
  • Defining goals and checking on them regularly
  • Avoid “fire fighting”
  • Learning to work *with* a problem person
  • Learn to say “no”

I feel this is pretty good value for a day’s worth of learning! The most common feedback I received was that it was so much fun.

Feedback

The workshop received an overall rating of 4.57 / 5 stars. Wow! I also received the following feedback:

“Most interactive workshop I’ve been into. For me changing the mindset to [test manager] and thinking in this way about testers and test teams was a new way to look at it.”

“Loads of fun and very educative. Learned a lot by failing hard. I do recommend attending this workshop when you have the chance.”

I also requested some constructive criticism which I gratefully received, and I will use this to improve this course even more.

Want to take this course?

You can! Go to my training site Transparo to register. If there are currently no course dates available, you can sign up to my mailing list to be be notified as soon as I’m able to run it. Or if you’d like me to run this course at your company or event, drop me an email and we can discuss.

Leave a Reply