The agile way to achieve boatiness

Game development requires planning in order to be structured. The extra work required to do the planning is worth it because it makes the rest of the work easier. Going for an agile framework over a traditional one is usually preferred for software development.

Making it go around

boaty iteration
Boaty.

In agile development, the product is broken up into pieces, with the goal being incrementally improving it throughout the iterations. An iteration is one of many work cycles in the development process. At the end of each iteration, a product is delivered. In this particular project, one iteration equals one week of work.

Working as a team

There are several different frameworks for software development. In this particular project, we are forced to work with scrum, which is one of the most popular agile methods within the game industry.

The old

Traditionally, a product would be developed in one of the many variants of the waterfall model. The waterfall model has a start and an end, along with all the necessary steps in between to make a releasable product.

waterfall.png
The waterfall model.

The new

The waterfall model is old and doesn’t really suit the growing software development industry. For software (including games), one favors agile methods because they allow for more freedom during the development, which ultimately results in a more refined product. This is quite noticeable during our work on the game, because there is so much room for testing and improvement in between the sprints.

scrum.png
A simplified model of our scrum framework.

As mentioned earlier, our sprints each last one week. At the beginning of every sprint, we carefully plan all of the work that has to be done before the end of the sprint. This includes things like assets that has to be drawn, functions that has to be coded, documentation etc. A daily meeting, the so called stand-up meeting, takes place every day during the sprint. The meeting ensures that all members of the scrum team is up to speed with the sprint plan. At the end of every spring, a product is delivered. In our case, this means a new version of our game.

What’s boaty about this?

The cool thing about working with scrum is that there is lots of room to improve the product. Because we deliver the game every week instead of once at the end of the development, we’re having an easier time testing and fine tuning the boatiness of it. It also allows us to make drastic changes to the game in case something didn’t end up as we expected it to. Had we followed the waterfall method, this wouldn’t really be possible.

Another great thing about scrum is that it encourages more teamwork. The daily meetings and the weekly planning sessions are all done together. Every team member has a chance to provide input for everything that’s being planned.

The backlog

All of the planned work goes into the so called backlog. The backlog holds all the entries for each iteration as well as the whole project. It has been very useful to record all of the tasks and make detailed plans for what to work on and when to do it. Having this centralized table for all of the work also helps with organization across the different roles in the team. It’s very easy to see what others are working on and therefore allows for better collaboration.

In addition, the backlog gives us an overview of the project as a whole, and tells us if we make changes or cut content in order to meet the requirements. This has happened several times already.

Hazards

Working with an agile framework has helped us a lot, but sometimes it can also be a setback. Usually, a scrum project has an iteration length of 2-4 weeks, which is much longer than our current iterations of only one week. The short sprints makes for a more intensive scrum learning experience, but has the side effect of requiring more hours per week for planning and meetings, when they instead could have been used for working on the game.

 

About Kentaro Hayashida

2017 Game Design