Agile Game Development – A Quick Overview

By Raluca | Uncategorized | 0 comment | 18 August, 2016 | 3

In this post I would like to share with you an overview of the Agile Game Development.

I was wondering how agile processes would be applicable to game development and I was very happy to find cool stuff over the internet about this subject. In the last part of this post I shared a few links that helped me to build this presentation about Agile Game Development. If you want to know more about this I definitely encourage you to go through bibliography because there are some amazing videos describing how agile is applied to game development.

What is Agile Game Development ?

Agile is an approach for developing products (in this case: games) using short iterations. The main idea is not making the whole project from start to finish, but making small features for the current project in small periods of time. In this way the results of each iteration are used to adjust the project plan:

each iteration is like a short project in itself
uses “inspect and adapt” practices to adjust the goals and measure progress

Figure 1. Traditional approach vs. Agile approach

Agile Game Development adopts the agile planning over traditional planning. In Figure 2. a comparison between these two methods is displayed.

Rather than doing all of one thing at a time, is better to do a little of everything all the time.

Let’s say that we have a great idea of a game and we want to implement it. In traditional planning we should step through those 4 phases above stated: Discover, Design, Develop and Test. Once a phase is completed, then we follow the original plan step by step by starting from one point and plan the directed work since a final goal is achieved. When the game is finished and we are ready to ship it to our users we risk to face a big problem: we have the perfect game played by nobody. At this point, we are forced to change the plans and try to do things that our users want. That’s why our End could not match the initially defined Goal. This means that when we start to make a game we deal with a big “Cone of Uncertainty”. Agile planning comes with small goals set for small periods of time and forces us to step through all those 4 steps each iteration (about 2-4 weeks long). At the end of each iteration we take a breath and look backward and try to conclude the results. Using these results and the users need we can adjust our initial plan and create some new goals. This process iterates until our deadline is achieved.

Figure 2. Traditional planning vs. Agile planning

Agile approaches help us respond to unpredictability through incremental, iterative work cadences and empirical feedback from users. When we start to deliver a project we deal with different types of noise level, depending on what we need to do (i.e. game requirements) and how we do it (i.e. technology used). Based on these two dimensions we can classify our project in 4 types of problems:

Simple – we can solve the problem by applying a predefined plan
Complicated – we can split the problem in smaller simple problems
Complex – we can use an empirical approach in order to see if the results are going in the right way
Anarchy – totally chaos

project noise level - agile game development

Figure 3. When to choose the SCRUM process (source: Strategic Management and Organizational Dynamics by Ralph Stacey in Agile Software Development with Scrum by Ken Schwaber and Mike Beedle)

A game is part of the complex class because the output is influenced by so many external factors and we need to inspect ourselves as soon as possible, try to get feedback for our game as early as we can and adapt our plans according to our results. And here comes the SCRUM process to help us.

What is SCRUM ?

SCRUM is an iterative and incremental Agile process that produces demonstrable working software every 2-4 weeks. Being results- and commitment-oriented it has a long history of success on a wide variety of projects, including game development.

Based on a product backlog that contains many features, the SCRUM process helps us to establish some goals for small periods of time that are called sprints. Usually sprints are 2-4 weeks long. Once a sprint goal is defined, then a set of tasks can be taken for development in order to achieve that goal. At the end of the sprint, the team is able to ship an incrementally improved game. The result is fully functional and testable by users so that each developed feature can receive that feedback that helps the game development team to find the FUN needed in order to have a successful game on the market.

Figure 4. The SCRUM process (agile game development)

SCRUM facilitates feature iteration, allowing teams to deliver polished, tuned and integrated features which can be used to test the creative quality of the game throughout its development, allowing the team to incorporate audience feedback as early as possible in the development process.

The SCRUM project community involves 3 roles with different responsibilities:

Product Owner
- Is responsible for the profitability of the product (ROI)
- Prioritizes features according to market value
- Can change features and priority every sprint
- Accepts or rejects work results
- Defines the features of the product, decides on release date and content
Scrum Master
- Ensures that the team is fully functional and productive
- Shields the team from external interferences
- Ensures that the process is followed.
- Enables close cooperation across all roles and functions and removes barriers
- Participates in daily scrum, sprint review and planning meetings
The Development Team
- Cross-functional, seven plus/minus two ideally full-time members
- Selects the sprint backlog
- Has the right to do everything within the boundaries of the project guidelines to reach the sprint goal
- Organizes itself and its work
- Demos work results to the Product Owner

scrum community in agile game development

Figure 5. SCRUM project community (roles and responsibilities)

Meetings, or ceremonies are an important part of agile game development:

Sprint Planning Meeting

Product owner describes priorities
Team breaks product backlog items (features) into tasks
Team commits to some amount of work

Daily Scrum

Three questions:
- What did you do yesterday?
- What will you do today?
- What’s in your way?
A commitment between peers, not a management status meeting

Sprint Review Meeting

Team demonstrates what was accomplished
2-hour prep time rule
No PowerPoint!
Anyone can attend

Sprint Retrospective

Focus on continuous improvement
Look back at the last sprint and ask what would we like to:
- What went well
- What we need to improve & actions
- Impediments

Figure 6. The sprint cycle

Bibliography

Hopefully this article makes sense to you. If you need further details please let me a comment and I will get back to you. Happy game delivery with agile game development!

Agile Game Development – A Quick Overview

What is Agile Game Development ?