CS 415 - Agile Game Development

Agile Development

Reference: Clinton Keith, Agile Game Development with Scrum, Chapters 1,2.

Waterfall and Agile Processes

PONG - First documented video ping-pong game (1969): video

Is the waterfall process really the source of all evil? What abut the Nike software engineering process: "just do it"?

How would you implement PONG using the waterfall process? What about improving it using several iterations?

Agile manifesto:

Major Reasons Why Projects Fail

Feature creep
Features are added to the project after the original scope is defined. This can happen either because a) new (emergent) requirements are demanded by the stakeholders or b) because original features fail/underperform need to be replaced/modified. However, feature creep and change are inevitable. Main reason for feature creep: BDUF (big design up front). Goal of BDUF: answer all questions about the project as early as possible. Gaming aspect makes it even more difficult: how will we know which parts of the game will be more fun/realistic/appealing until the game is playable? However, uncertainty diminishes significantly throughout the project. In a waterfall project, resolving uncertainty is delayed until the testing phase. In an agile project, uncertainty is eliminated little by little in iterations throughout the entire project.
Overoptimistic schedules
it is difficult to make predictions, particularly about the future.
Factors leading to failed time estimations:
  • Unexpected problems/events
  • Team productivity varies depending on the composition
  • Multitasking
  • Gaming factors: unknown how many iterations will be needed until a feature is "fun to play"
The Challenge of Production
Pre-production: exploration of what the game is. Challenge: find the fun that would drive the goals of production.
Production: building content. Challenge: maximize efficiency, minimize waste, create predictability.
Uncertainty has to be reduced a great deal before the production can commence. However, it is inevitable that some pre-production and production will overlap. Production includes assets such as level designs and characters, which makes it critical not to rush into producing them too early.

Why Use Agile?

Knowledge is key
It is so important because:
  • Its creation is something that occurs during the project;
  • It has a great deal of value;
  • Creating knowledge has a high cost;
  • Knowledge is the greatest asset a team can create.
BDUFs are the biggest issue with the waterfall model: not everything is known in advance. Knowledge about a software development project (especially a game) is generated while it is being created. Game development is primarily about learning what to make and how to make it. It's about reducing uncertainty over time. Agile development focuses on building knowledge about value, cost, and schedule and adjusting the plan to match reality.
Improved quality by finding the fun first
In iterative development a product is created in small steps by incrementally adding features that satisfy the customer in the fastest and most economical way. In a waterfall project, features are not functional (and fun cannot be found) until at least 2/3 of the way in.
Decreased costs by eliminating waste
By "finding the fun" first, the project team finds the value early in the project rather than trying to retrofit it at the end. By delivering working software iteratively, a project can prove whether an idea is viable earlier in development. This makes it possible to enact the kill-gate model where a dozen ideas are launched and narrowed down until the best remain.

What an Agile Project looks like

An agile project is composed of a series of iterations of development. Iterations are short intervals of time, usually two to four weeks, during which the game development makes progress. At every iteration, developers implement individual features (user stories) that have value to customers.

The game is reviewed at the end of every iteration, and the results influence the goals of future iterations, which is an example of using the "inspect and adapt" principle. Every four to eight iterations, the game is brought to a release state, which means that major goals are accomplished and the game is brought to a near-shippable level.

The "inspect and adapt" principle is the cornerstone of agile practices. Teams and customers inspect the progress of a game at every iteration and adapt the plan to address what is valuable and what is not. Teams inspect how they are working together at every iteration and adapt their practices to improve their effectiveness. Using this principle projects can achieve better results sooner through the ability to steer the plan toward a more desirable goal.

Customers and stakeholders identify features and other requirements (e.g. tools and infrastructure needs) for the game. These features are placed on the product backlog that is prioritized by the product owner. These product backlog items (PBIs) are expressed as user stories that communicate the value of each PBI to the customers and stakeholders. Small Scrum teams of developers commit to completing one or more user stories from the product backlog every iteration and demonstrating them in an improved version of the game. A ScrumMaster assists each Scrum team, helping them remove impediments to progress and ensuring that they are following the agreed-upon process.