The Path to Become Agile: Part I

A new series of blogs that will document my experience implementing the Agile Methodology into game development.

November 9, 2015

4 Min Read

Introduction

This is the first part to a new series of blogs that I will be writing. If you’ve ready any of my previous blogs, I am currently studying at the University of Advancing Technology to receive my M.S. in Game Production. At this point in time, my assignment has been to begin implementing the agile methodology within a game production role. As you may know, the agile method is an industry standard nowadays among larger game companies due to its adept ability to create a cohesive team environment and development cycle. This and the following blogs will document my journey through my current development cycle while attempting to utilize the agile methodology.

Software

We have been reading from “Agile Game Development with Scrum” by Clinton Keith and have been given the opportunity to use software called Axosoft. This software will allow us to input our current projects into it, add in team members, create sprints and features, assign team members, and track the development process throughout each sprint. This will be my first time utilizing this kind of software so this should be interesting as time progresses.

The Game

The game that my team will be working on is called Super Bit Adventure. Signing up for this change in development comes at when the game is already almost 50% complete. This allows me to get a taste of what the development cycle was like before and after implementing the agile method. Super Bit Adventure is an action RPG for mobile devices. It is meant to capture the nostalgic feeling of old school RPGs and the spirit of Zelda: A Link to the Past. Check out the links below for where you can keep track of its development.

Sprints

If you’re already familiar with the agile methodology, then you already know what a sprint is when it comes to development. For those who don’t, a sprint is a two to four week period where your team works on a set number of features for your game. These features can be either new additions to the game or bug fixes. The point is, within this period of time, any new features or bugs should be completed, tested, and ready for shipment by the end of the sprint. At the end of the sprint, a sprint review will take place to see what went right and what went wrong. This will allow for better sprint planning moving forward into the next one.

For this class we are a bit constrained in time so I have made the decision to create one week sprints. Making this decision causes me to ensure the features we plan to add for this spring isn’t anything too code intensive that more than a week will be required. I want to try and set realistic goals throughout each sprint that we have. In addition to coding new game features, I’ve added a few tasks for me to do that fall under marketing and art for the game.

Looking Ahead

So far things have been looking pretty good for the first week of agile. The sprint has been loaded with achievable goals and we have been working diligently to get everything done so at the end of the spring we have a “shippable game build.” This is the goal after each sprint so we must make sure that everything is done and tested prior to the end. Using this software has allowed us to keep track of not only the things we are working on, but each other as well. This gives us a feeling of responsibility now that we physically have eyes on whatever the other developer is currently working on. In my opinion, it helps push the team to do better and work harder. This is still the first week so I’ve only dipped my toes into agile methodology. You can expect more in the upcoming weeks on my thoughts for the whole thing on a weekly basis.