Agile vs Waterfall - The Agile Approach
This article is the second in a series exploring how we can apply Software Development principles and practices to designing Tabletop Role-Playing Games. This 3-part series looks at Software Engineering Methodologies and what we can learn from them to help us design games better.
Part 1 - Agile vs Waterfall - The Waterfall Approach
In the previous article, I talked about the Waterfall approach and what lessons we could take from it to apply to TTRPG design. That article outlined several issues with using Waterfall for both software and TTRPG design. Let’s just remind ourselves of those issues before we dive into the ways that an Agile approach can help solve them.
1. Dependent on requirements
For Waterfall to be successful, you have to know EXACTLY what it is you are building before you start building it, and any flaws in your planning at this stage can have major unforeseen effects down the line.
2. Inflexible
Related to point 1 above, changing things during the course of the Waterfall approach is hard, leaving you with an expectation to build perfection from the outset.
3. Test feedback
Seeking feedback so late in the process means that you don’t know how “good” the thing you are building is, or even if it works.
The solution to these problems? Agile!
The key thing to understand about Agile is that it relies on the concept of iteration. In this context iteration simply means building a complete thing over a period of time and getting that thing into the hands of users. I use the term “thing” here purposefully. A “thing” need not be a fully functional application with everything it needs to do implemented or a complete TTRPG with character sheets, every mechanic ironed out and every edge case handled in your 300-page rulebook.
Let’s dive into the process.
Plan - Seems a bit similar to the first step in the Waterfall process right? Requirements gathering? However, in the Agile process, we aren’t planning the whole project. Instead, we are looking (at least in the first iteration) at the Minimum Viable Product (MVP). This means that we are trying to work out what features are required to deliver the ABSOLUTE MINIMUM that can be used and plan a sensible order in which to deliver those things.
How this applies to TTRPG Design - The tricky part here is going to be working out what the MVP is. What is the bare minimum amount of work that you could do to run a playtest of your idea? Defining an MVP is a skill that even the most experienced software development teams and Agile managers struggle with, so don’t beat yourself up if it seems uncomfortable or hard. Taking the example from the previous article, if our idea is a rules-lite Lazers & Feelings hack that uses D20s instead of D6s and explores themes of loneliness amongst researchers in the arctic circle, how little of this could you put in front of people to see if it works? If we take a little of the mechanics (D20 with 2 Skills) and a little of the theme (artic circles research/loneliness) our MVP could be running a single scene in a research lab with 2 characters. The Plan stage here would have us outline what we need to do to run that scene. Could you do this without a character sheet? Yup. Could you do this without defined combat mechanics? Yup. Could you do this without knowing what skills the characters have? Probably not. Could you do this without knowing how the outcome of dice rolls is resolved? Again probably not. So we are starting to define what it is that we need to develop in this first iteration for functional MVP. We need to decide what the character skills are, how we resolve dice rolls, and a problem that 2 or more characters might be trying to solve. AND THAT’S ALL. It’s important at this stage to articulate that goal. Write it down in bold. Seriously write it down. A very common problem at future stages is what is called Scope Creep (allowing additional features and work to become part of the iteration) and it complicates the process and does not help you get towards your MVP. Writing down the goal for each iteration and referring back to it will make it less likely that you will drift back into a Waterfall approach.
In future iterations, we are expanding on this MVP, adding one or more features to it, and repeating the process again.
Design/Develop - This stage is where the bulk of the making of the thing happens. Based on the defined goal for this iteration, changes to the product are made and implemented, ready to be tested.
How this applies to TTRPG Design - This stage is where the real work is. For our MVP iteration it might be quite simple; Write down some skills, say Malaise and Science, and assign them what might be considered reasonable values, for a bit of variety to see how different character types would work, you might have one high in Science and low in Malaise, and the other with the opposite. Then write out a simple problem for them to solve. Since we are looking for MVP (emphasis on the M for Minimum!) we would want to keep it light and straightforward, with bullet points rather than a novella. As we progress through iterations, however, the Develop phase may become significantly more complex. When you are four iterations in and you discover an issue with your dice mechanic that means assigning certain values to skills causes players to succeed at everything they try to do, solving that problem requires really sitting down and working through how to solve it without breaking everything else.
Test - Pretty self-explanatory. In software engineering, this step is usually performed in a variety of different ways, often by different people. The developer will run their code on their own computer and (in a perfect world, though it often doesn’t happen) write something called unit tests (basically a test of the smallest consumable unit of code) to verify that there are no obvious issues with what they have implemented in the Develop stage. Once the feature is what’s called “Development Complete” it’s deployed to a test server for the Test team to run whatever testing they see fit. Usually, they will cover things like regression testing (making sure that nothing has changed other than what was intended) and run the feature through a range of scenarios that a user could feasibly perform, though most users would not to verify the feature and systems ability to handle both normal use as well as edge cases. I could write a lot more about the types of testing that can be done but that’s not for this article!
How this applies to TTRPG Design - Similarly to software, a variety of test options are available to us when designing TTRPGs. The first and easiest step would be to run through the scenario that we established in the Develop phase ourselves, playing 2 or more of the characters in the scene to see if there are any obvious issues (seeing the parallels with software and TTRPGs?). Ideally, beyond this initial test, you would recruit at least one other person for something akin to a playtest. You aren’t doing a playtest of a full game though, you are just testing out that MVP or whichever iteration you are currently working on and believe to be “Development Complete”. Having written down your goal in the Plan step, you should have a pretty clear idea of what you are testing and can ask pointed questions about that to the person or people you are testing with. In the example we have been working with we might ask “How well did those skills lend themselves to the theme?”, “Did a D20 roll work with those skill values?” etc.
Deliver/Deploy - In the purest terms of Agile, after testing MVP or any iteration of your product, you deliver that product into the hands of users. REAL USERS. Which is scary at best. This means pushing a specific feature, or MVP or any iteration to a production environment for users to use and get used to. And this works in PURE Agile. However, in the real world (particularly in early iterations) this is often not the case. Often this step is skipped along with the Review stage, returning to the Plan stage and starting the next iteration until there is a valid and usable MVP in place.
How this applies to TTRPG Design - I would argue that this stage is the hardest one to apply to TTRPG design. Sorry for pulling the rug out from under you this late into the article. But TTRPGs are NOT software. With software you can throw an MVP with a couple of features and a couple of screens at users and know that it’s not done. But from there you can iterate and improve and add features. How would that even look for a TTRPG? You, uh, release a PDF? And then everyone is mad at you for your broken game? Or god forbid you send it to the printer then ship it to people? Even thinking about the cost of doing that makes me a little bit sick. This is a real problem in both early phases of a project for software, and PARTICULARLY for TTRPG design. The solution to this problem is something that we are going to get into in the next article where we look at the oft derided and maligned WAGILE methodology :)
Review - Ok this a stage that we can get behind. If we were dealing with software, we could look at many different aspects. We could look at the feedback from users that we delivered to in the Deliver phase. You might have received feedback from users like “I love what you are trying to do, but I want to be able to do X”. In the review phase you would start looking at all those X’s that people are mentioning, decide which one is the highest value and then bring that into the Plan stage when you start your next iteration. Or you might review something that came out of the testing phase, such as an odd edge case that would maybe come up 1 time out of a 1000. Additionally, you may have identified things in the Plan stage that would be “nice to have” but maybe didn’t quite make the cut for the MVP. You can bring the outputs of all of these stages to your Review stage and feed the ones that you think will add the most value, or that you are most excited about, to your next Plan stage.
How this applies to TTRPG Design - This stage is probably the most directly relatable to conventional wisdom about TTRPG or general game design. In TTRPG design we should already be doing this regardless of Agile or Waterfall or whatever methodology (or lack thereof) that we apply. This could be incorporating feedback from the playtesting you are doing or how you feel about your design so far. However, I would caveat that this stage is important to formalise. Write it down. The feedback from your personal, private tests and the feedback from your test with a couple of friends if you managed to run one and the things that you think might be interesting additions for you next iteration. WRITE THEM ALL DOWN!
Next Steps
The next steps in Agile design are to simply rinse and repeat the steps above! You deliver an MVP and then feed the outputs of your Review stage into your next Plan stage. Iteration after iteration you get closer and closer to project completion.
Now you might be seeing an obvious issue here. How do you know when you’re “DONE”.
Correct, well observed. And that’s a “problem” with Agile, you are never done, you are only ever iterating and improving (this is a concept known as Continuous Improvement and I could write a hundred more articles on it). “But that doesn’t help me release a game!” - I hear you cry. I know, it doesn’t and there are ways around it, but those will have to be dealt with in the next article.
That's it for this time. In the next article, we’ll take a look at how we can combine the best parts of the Agile approach with the Waterfall approach to get towards delivering TTRPGs in the real world!
And I already have future articles planned about the various approaches to implementing Agile into your game design. Keep an eye out!
If you haven’t already, I recommend taking a look at the Agile Manifesto here.
Thanks for dropping by! If you have any questions or comments, please leave them below.
You can also find me on Twitter.
Take Care!
Anthony