One of my personal projects is the Firefight! Tactical Roleplay Engine. It is a live-action game system designed for use with airsoft. For the most part the project lies outside of the digital domain but the goal is not that different from that of a software project – to deliver a working system.
Non-techie readers, there’s a bunch of vocabulary here but have no fear. I’ve linked terms to definitions.
In The Beginning
Our process revolved around bare bones development iterations. It was pretty simple; we’d develop a chunk of system, write a game event to test that chunk, run the event, hold an informal retrospective and start the next iteration. This approach served us very well in getting the game system off the ground. The first iteration turned out to be an incredibly short 24 hours from initial concept to the first play test event. But since it is a live-action game where you have to organize an event and get people to the same location for testing, iterations tended to be longer than desired. Seasonal weather impacts event scheduling which means that iterations are of irregular length. And of course writing and coordinating events uses large portions of our available time. With these issues in mind we realized that we had to make the most of our development and testing opportunities.
As complexity of the project increased it was becoming ever more difficult for me to manage and communicate progress even though we had a development team of only two people including myself. Most critically, if I was pulled away by an outside force (danged day job!) then the entire project screeched to a halt even if the other developer was available and waiting to work. I was the bottleneck which was completely unacceptable especially considering the size of the team. This had to change.
I had experience with Agile on software projects so I began pondering how it could be applied to game design. We were already doing a form of Pair Programming where we worked side-by-side to develop and codify ideas. And we were already doing iterative development. We wanted to enhance our adaptability, increase transparency, favor simplicity, and foster unity. These agile values mapped directly to our game design goals.
Initially, we turned to Scrum. It wasn’t a perfect fit but it was a good first step.
- Scrum got us thinking about what exactly it was that we were building.
- Our list of requirements and ad-hoc use cases became user stories that we could better evaluate and revisit.
- For the first time we were really and truly looking at things from a player’s perspective. This amplified the usefulness of their feedback.
- Short standup meetings had a positive impact on our motivation. A big problem was that the project could sit idle for periods of time due to burnout. Relying on flashes of inspiration to nudge us back into action is obviously not a good way to get things done. The standup meetings kept us primed and moving.
- We were no longer just running on gut instinct informed by experience.
The not so good:
- The reporting components of Scrum didn’t work that well for us. We weren’t able to increase visibility because our burndown chart was wacky because estimation was downright tricky. We simply didn’t have the necessary experience to estimate how long it would take to convert a rule concept into something fit for play. And the velocity chart wasn’t useful because we simply had no idea how to tackle business value during early prototyping.
- The typical example task board while incredibly useful for visualization wasn’t granular enough to build flashlight metrics for wayfinding. At the time I was so focused on everything Scrum that I couldn’t see how to break the board down into smaller steps.
- I (acting as ScrumMaster) was still the bottleneck. See next bullet point.
- I felt overwhelmed far more often than I’d like to admit – like I was juggling too much.
It didn’t take long to figure out that pure Scrum really wasn’t a good fit so we moved on taking with us the bits that worked; bits like time boxing, standup meetings, user stories, and the concept of the task board. We kept moving forward but we soon bogged down a bit from spending too much time examining process. Then things took a lighter turn.
Here’s the definition of Kanban at Wikipedia:
Kanban can be divided into two parts:
- Kanban – A visual process management system that tells what to produce, when to produce it, and how much to produce.
- The Kanban Method – an approach to incremental, evolutionary process change for organizations.
In our case A visual process management system is a complicated way of saying, “A board with post-it notes stuck to it”. In a future article I’ll cover how we created our Kanban board for game development.
One tremendous benefit of a Kanban board is that virtually everything is right there for everyone to see at their leisure. This virtually eliminated the management bottleneck. Out of the gate I was doing less management with no sense of juggling.
Other great features include flashlight metric building and process improvement both of which are intrinsic parts of the system. Everyone can see the steps for creating value. And when tackling tasks that you’ve never attempted before you will eventually know exactly how long they take to complete. Building this kind of institutional knowledge is incredibly valuable. A direct benefit is that we are now able to examine both game design itself and the process by which we are creating ours.
Who knew that you could get so much by doing less?