The Skinny On Agile Game Design – Part 1

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.

Enter Agile

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.

The good:

  • 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.

Getting Lean

When I discovered Lean development via the ebook Kanban and Scrum I was thrilled. It was exactly what we were looking for. Kanban in particular immediately jumped to the fore.

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.

This is the Firefight! Kanban board as of June 2010. It has changed since then.

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?


3 thoughts on “The Skinny On Agile Game Design – Part 1

  1. Institutional knowledge…is that what made D20 and the OGL so powerful a model? I think so. Institutional knowledge can also pertain to the consumers, especially with games. Creating new “editions” can shatter that sort of collective experience. Hmmm.

    In other words, with tabletop RPGs, I see these concepts potentially applying to the playing community as well as the designers. Sort of a symbiotic relationship.

  2. By institutional I meant shared with/available to everyone in an organization vs. tribal knowledge known only by small groups within an org. So, yea, I think you’re onto something – and very interesting that you mention the OGL when I’m considering an open license for our upcoming game system as well as what “community” really means for the game.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s