4 min read

I Put On My Robe And Wizard Hat

I Put On My Robe And Wizard Hat
All credit to Marvel Productions and D&D Entertainment. And the 80s. Also bloodninja of course

Want a good team building activity that encourages a group of people to work collaboratively using their unique skills and capabilities to creatively solve problems?

What about something that actively encourages out of the box thinking in the face of challenges that are constantly adapting to their actions?

Do you like being surprised by the interesting (and sometimes insane) ideas that your colleagues come up with when faced with unusual situations?

If any of that sounded interesting to you, you should consider introducing a tabletop game like Dungeons and Dragons to your organization.

Desks and Deadlines

Lets be honest, there is a good chance that you’ve heard about Dungeons and Dragons before, probably because you’ve watched Stranger Things. I’d wager a guess that people are generally more familiar with D&D than they are with the general concept of tabletop gaming, but at a very high level its a meeting where a smallish group of people sit in a room together for a few hours and collectively hallucinate vividly.

All jokes aside, table top role playing games are very much a team based problem solving activity, driven by a somewhat pre-planned outline, and constrained by a set of rules and guidelines. They can be as complex or as simple as you want, and are constantly adapting and reacting to the actions of their participants.

The official D&D website is a great place to start reading if you’re interested in finding out more, but most of those documents focus on the fantasy, and less on the social and team building aspects, so keep that in mind.

For a simple explanation, in D&D there are two roles:

  • Players
  • Dungeon Master

Both roles participate in the game, but have very different goals.

Players choose some set of skills (which automatically come with an equivalent set of limitations) and work together to solve a series of problems within the context of a grander setting. Typically there is a story at play, providing high level direction, but on a session by session basis they generally solve much smaller problems in relative isolation. There are typically five players, but anywhere between three and seven is probably okay.

The dungeon master plays the opposite side. They are responsible for providing challenges to the players within the greater context. It can be a difficult role to play, as an overbearing or controlling DM leaves no room for players to innovate and be creative, but a weak or distant DM leaves everyone disengaged and unhappy.

Sound familiar?

+2 Agility

Like most team based activities, its easy to draw parallels between D&D and agile software development. A group of empowered people with a wide range of skills focused on solving problems within a greater context?

That’s a pretty textbook definition of an agile team.

Of course, its a lot more fun to sweet-talk a dragon into not eating you than it is to build accounting software (unless you really like numbers), so it can be quite beneficial to use the softer, more engaging game to create and strengthen team dynamics.

Lets have a look at the capabilities required to participate as a player in D&D.

Players are expected to be able to:

  • Be creative and come up with a character, given a set of rules and templates to work within
  • Be able to put themselves in the shoes of that character, seeing the world from their point of view and acting accordingly
  • Understand a complex system of rules and constraints
  • Be able to think quickly and react in the face of changing circumstances
  • Understand that there are real consequences (within the context) to actions
  • Understand the skills and limitations of the people they are playing with, such that together the group is greater than the sum of its parts

I’m not going to go into each point in detail, but there are a lot of things there that are easily applied to delivering quality software.

For example, the second point (being able to put yourself in the shoes of your character) can be used to empathize with the users of your software. A pretty common UX approach is to come up with personas for your most common user types, and if the members of the delivery team have the ability to both empathize and think like those personas, you’re almost certainly going to get better results than if the team were just plugging through some arbitrary set of features with no thought to the greater context.

From my point of view, if I had a group of people who exhibited most of the traits that I outlined above, I’m sure I could point them towards almost anything and they would nail it.


This whole post is relevant because a small group of us have been playing D&D in a work context for a few months now, and its pretty amazing. I think its important to share these sorts of experiences, both to show how much a difference a good work environment can make, and to give other people ideas.

Our current group is drawn from across the entire business, rather than being a team that already work together, which is a shame, but even then I’m more familiar and friendly with everyone in the group than I would have ever been without D&D. Its similar to the effects we saw (and continue to see) from the Mario Kart Tournament, a higher level of general bonding and familiarity that leads to a whole suite of beneficial day to day side effects.

Like most things (professional development for example), the hardest part is always finding the time. Everyone has lives and other commitments that can easily get in the way of this sort of activity.

That’s where the business can help.

If the organization can agree to sacrifice an hour or two a week, they can reap a whole bunch of social benefits for very little investment. Just having all the participants already in one place is a massive boon from an organizational point of view.

For me, if we ever manage to finish our current campaign, I’m very interested in expanding the program to specific groups of people that are already working together, and testing to see whether or not the improvement to the team dynamics flows through into their day to day activities.

I’m pretty sure it will.

This post was originally made waaay back in 2018 on my old blog, Code and Compost. I've migrated it here because I wanted to link to it and I didn't want to encourage people to go to my old blog at all.