There are a million ways to run tabletop roleplaying games like Dungeons & Dragons. It can be difficult to know which frameworks and methodologies to go with. But in the world of software development, Agile provides a battle-tested, flexible approach to delivery. What if we could adopt it for running games?
A Manifesto
The “Manifesto for Agile Software Development” states the following:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more.1
Adopted for tabletop roleplaying games, it might say:
We are uncovering better ways of running games by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Running games over comprehensive documentation
Player collaboration over contract negotiation
Responding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more.
Simply changing three words makes this work for tabletop roleplaying games.
Principles
There are twelve principles behind the Agile Manifesto. Let’s change them to fit tabletop roleplaying games.
Our highest priority is to satisfy the
customerplayers
through early and continuous delivery
of valuablesoftwaregames.
The premise for all of these is that play is the pinnacle. We can optimize our prep and go the extra mile with worldbuilding but play is the goal. The term “players” also encompasses the game master.
Welcome changing requirements.
, even late in. Agile processes harness change for
development
thecustomer’s competitive advantageplayers’ enjoyment.
This is a creative hobby that requires a lot of improvisation. Changing requirements are the norm for us: a player drops out last minute, the party goes left instead of right, someone wants a new character. We welcome that and lean into it, always aiming for the enjoyment of the players.
Deliver
working softwarereal games frequently, from a
couple ofweeksdays to a couple ofmonthsweeks, with a
preference to the shorter timescale.
This might be the hardest to achieve, yet the most important. Run games and run games often. This is how we deliver the actual value to the group and it’s how we learn and get better. The more frequently we run, the lower the chance of stagnation and abandonment.
Business people and developers must work
together daily throughout the project.
If these were targeted towards game developers and designers, this principle might have a place. But it’s aimed at game masters. As such, I don’t think there’s anything we need from it.
Build
projectsgames around motivated individuals.
Give them the environment and support they need,
and trust them toget the job donedo the rest.
Players (including the game master) should be motivated. Focus on the ones that are. Build them the environment and support they need and let them cook. Let unmotivated players either catch on or fade away.
The most efficient and effective method of
conveying information to and within adevelopmentgaming group is face-to-face conversation.
team
Communication tools like adventuring agreements are one example of this. Prefer face-to-face conversations for play, world/character building, and conflict resolution. In person is best with video calls being a decent substitute.
Working software isActual games are the primary measure of progress.
Again, play is our pinnacle. If you’re not playing, you’re not delivering the real value to your gaming group.
Agile processes promote sustainable
developmentgames.
Thesponsors, developers, and usersgame master and players should be able
to maintain a constant pace indefinitely.
If the way you prepare, worldbuild, or schedule your sessions isn’t sustainable, it’s not agile. Make tweaks so you can sustain all parts of the lifecycle indefinitely. Shorten sessions, streamline notes, etc.
Continuous attention to technical excellence
and good design enhances agility.
This one may land a bit more abstract but I think it’s important. There are aspects of “good game/adventure design” that are more universal or battle-tested. Use them. One example is giving players agency with meaningful choices. Another is dynamic combat. Focus on the “excellence” of your game’s design, whatever that might mean to you. But build off of the shoulders of giants.
Simplicity—the art of maximizing the amount
of work not done—is essential.
Paging Mike Shea…But seriously, keep things simple and maximize the amount of work that you’re not doing. Offload initiative tracking to players, roll for details rather than prepare them, use static damage, etc.
The best architectures, requirements, and designs
emerge from self-organizing teams.
Let the party self-organize as much as possible. It brings clarity to your job as the game master.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
If it’s worth doing, it’s worth doing well. Creative endeavors are about growth. Regularly reflect on games to continue improving.
This was a fun exercise and I think it could be useful as general principles to game by. If you want the principles themselves, grab them from this page.
Game on.