There was never a choice whether to exercise agile methods for our project as it is dictated by the course the game is being developed for. Having that said, we probably would have used it given the choice. Agile development is a good fit for many projects and especially for game projects, in my opinion. The core idea is adaptation: the project is developed using iterations where the path towards a finished product can change direction as new requirements and requests are being catered to. This is well suited for game development as it allows us to easily add features, adapt to results from playtesting and quickly change goal if the game idea needs to be altered.
Our method
The process is mainly Scrum. First we create user stories for our project. A user story is typically written from the perspective of a player or developer, or another role significant for the project. It is a feature or technique that a person in that role would want to see in the game. We have divided our project into the smaller parts called sprints and decided on each sprint spanning two weeks. Each sprint has a goal with associated user stories and should work towards the very rough monthly milestones we have set up for the project to make sure we make enough progress to reach our final goal. This goal is decided upon during the sprint planning meeting at the beginning of a sprint. Then, the sprint’s goal is further broken up into smaller tasks (called Product Backlog Items or PBIs) which are estimated and put on our Scrum board for everybody to see. Our team has a velocity, which states how much work we can do each sprint and the total estimations for the tasks should not exceed this velocity.
To find out the velocity, we start by figuring out the unit for the velocity. Scrum suggests this is done by choosing a very basic task, giving that task an estimation (usually one unit) and then compare all future units to this one. That is, a task that takes twice as long as the basic task with an estimation of one unit takes two units – you get the drift. Then, we estimate how many basic tasks we could do as a group in the allotted time and that is the team’s velocity. As this is all very approximative, more so the less experience you have working with this method or working as a group, the velocity needs to be adjusted after a sprint. A good time to do this is during the retrospective, a more realistic value can be chosen as part of the evaluation. More on the retrospective below.
We also have the daily Scrum: a timeboxed, 15-minute meeting at the start of every work day where each team member accounts for what task(s) they worked on the previous day, what they are going to continue work on and what possible problems he or she may encounter during the day. This is a very good way of making sure all team members have an appreciation of what everyone else is doing and what state the project is. It also helps discovering and solving problems quicker. At the end of each sprint we have a retrospective meeting, as the Scrum process suggests, where we evaluate the sprint: what has worked well and should be continued, what did not work and should be changed and what new approaches do we want to try.
Lastly, we have an appointed Scrum master that for learning purposes is cycling through the team members interested in the assignment. Currently, I am the Scrum master and as such, my duties include facilitating meetings and solving problems that may slow team members down.
If we find bugs, these are put on the Scrum board immediately and discussed during the next daily Scrum to determine whether they are pressing and need to be resolved promptly, or if they can wait to the next sprint, as well as who takes care of it. This is in line with the Scrum policy that tasks are not finished until they are complete and bug free (as far as is possible to determine).
Apart from what we take with us from these agile processes, we also have an idea board for adding any ideas whenever you think of them. These ideas are then considered at the sprint planning meeting and either discarded, left for the future by going back on the board or incorporated into the process in the form of a user story, PBI or addition to the Game Design Document (GDD).
Disadvantages
We have had occasions where some team members have been stuck waiting for other team members to finish their tasks. This has left us less productive than we could have been although not inherently the fault of Scrum – some dependencies are inevitable, especially at the beginning of a project and some are due to our inexperience in planning and such problems will be avoided as we get better at planning.
Advantages
Several advantages have been mentioned above and include the easy addition and removal of features, incorporate changes based on play testing, all team members being up to speed with what everybody else is doing and the use of an iterative process. If we come up with new ideas we would really love to see in the game, they are easy to add and conversely – if we find that time is running out on us we get the chance to cut features. Same goes for the result of play testing.
That all team members know what everybody else is doing is very important and minimises misunderstandings, double work and error resolving. The Daily Scrum also propel communication within the group as an extra bonus for a newly founded group.
The iterative process allows us to change the direction of our project if necessary, scrap features and techniques that do not work in the desired way and even rollback entire sprints. Thanks to the retrospective meetings at the end of a sprint, we continuously improve the work process to make it more effective and less error prone.
Further Reading
If you are interested in the Scrum process and want to know more, I recommend the book Agile Game Development with Scrum by Clinton Keith (ISBN: 978-0-321-61852-8).
