Software development models

We'd like to help you better understand the production process and the path a game project takes. To achieve that, let's take a brief look at the two most common software development models, Waterfall and Agile.

Waterfall

Waterfall, as we understand it today, is a sequential approach to production with no space for iteration. The product is supposed to go through six rigid phases in a specific order (always trickling down, such as a waterfall):

1. Listing all software requirements
2. Analyzing requirements
3. Designing the whole product and its architecture
4. Writing and implementing all of the systems and content
5. Testing and debugging
6. Operations, support, and maintenance of a completed product

Since this process allows for no iteration, its use in games development is highly limited. It can, however, be applied on a small scale, be it on a part of game's content (asset production) or a single game feature with already proven mechanics and rock-solid specification. Applying waterfall on the whole product (with unproven mechanics and systems) would most likely result in a broken game that ticks all the boxes but is not fun to play at all.

Agile

Creating a highly polished and fine-tuned work of art is not easy, which is why games benefit greatly from extensive iteration. These iterative cycles are at the core of the Agile methodology of software development. The Agile Manifesto (http://agilemanifesto.org), which popularized the movement, has led to the development of several frameworks; Scrum is one of the most popular in the games industry.

Scrum

Scrum is traditionally best suited for teams of 10-15 people; for larger teams, there are modified versions such as Large-Scale Scrum and Scrum of Scrums.

Scrum itself usually relies on sprints (development cycles) that last a few weeks (usually between one and three), as well as short daily standup meetings (where relevant progress is being shared). Longer development cycles can be used but anything spanning more than four weeks hampers the iterative process and becomes very hard to plan. Flexibility is a core tenet of Scrum, and it has to be preserved by adhering to short (but still meaningful) sprint cycles.

In Scrum, a product owner (usually the producer) represents the interests of an end user and ensures that all development tasks are divided into a set of comprehensive tickets.

Tickets are virtual reminders of the work you have to do. Most teams use online ticket and bug tracking systems such as Jira, which offer easy to use dashboards and manage everything, from feature and content creation tasks to bugs and issues that come out of testing. Work done in each sprint cycle has to be properly tracked as tickets so it can be planned and tested.

A task to create a resource trading feature would probably take the shape of a user story (a task that's described from the point of view of the end user), starting with As a player, I can easily trade resources with my guildmates... and would be followed by a detailed set of functionalities and acceptance criteria, and possibly paired with a user interface mockup or a link to a relevant design document. These tasks are placed in the product backlog and wait for the end of the current development cycle. The backlog itself is a database of all tasks and bugs. It's usually handled by tracking software such as Jira and requires regular oversight from the production staff (including the designer).

On top of using software dashboards, many teams opt for a physical sprint board often placed on an actual office wall or a large whiteboard. The sprint board is where all relevant tasks end up, often in the form of sticky notes. Bugs rarely live on these boards as they are too small to track with such scrutiny. Moreover, bugs rarely follow the workflow of new feature and improvement tickets.
A physical sprint board is a great visual indicator and serves as the epicenter of daily standup meetings, where people working on each task share their progress and move the ticket across the board to reflect their progress. Commonly, sprint boards are divided into four columns: to do, in progress, testing, and done.

The sprints themselves can consist of multiple phases. For example, in a game that has already been released, a three-week sprint might have two weeks of development (after which all features are locked into place) and a week fully dedicated to bug fixing, testing, and a store submission of the improved version of the game. Each sprint formally ends with a retrospective and starts with a planning meeting. During sprint planning, any upcoming tasks are pulled from the backlog, estimated by their respective disciplines, and slotted into the newsprint.

Game designers working in Agile teams will greatly benefit from their iterative nature and increased flexibility, but only if they stay diligent! Once the development cycle begins, it is unlikely you'll be able to sneak in extra feature work. Any improvements and ideas you'd like to put into the game will have to be turned into concise and actionable tickets and brought to everyone's attention during sprint planning or backlog grooming (a regular analysis of all open tickets). Design documents and spreadsheets will rarely be seen by your teammates unless you include them in the tickets themselves.