As the gaming industry advances and evolves, new ideas can suddenly popup and change the way things goes in an instant.

I've worked for 2 years in a Agile-centered startup. I've experienced first hand what agility can do to boost productivity and reduce development cost. It's a really simple and pleasant thing to work with agility, and maybe the gaming industry can benefit from it.

The values

Everybody that knows agility should be able to understand the core values of the Agile Manifesto.

To put it simply, we should value:

1. Individuals and interactions over process and tools;
   (i.e. work geographically close rather than remotely or value genuine conversations over Skype)
2. Working software over comprehensive documentation;
   In our case, the game MUST be fun (or work correctly) before anything else
3. Customer collaboration over contract negotiation;
   Basically, make the player more involved in the game's development
4. Responding to change over following a plan.
   This is, of course, directly dependent of point 3

Also, keep in mind that it's mostly an hypothesis. As the manifesto states :

Quote

We are uncovering better ways of developing software by doing it and helping others do it

Doing Agile vs. Being Agile

During the past 2 years, our scrum master always warned us about the impostors, or the people that are "Doing Agility". Things like using a Kanban board or doing Daily Scrums wont make your team Agile. It's all about the values.

These tools should be used to apply those values rather than using them just because it's a trend. 

For exemple, some teams uses a Scrum backlog while locking it's content to everybody other that the project owner. This puts the project on rails, and can just be a waterfall process disguised as something agile.

How can the gaming industry can benefit from it?

As we keep seeing video games cost more and take a lot more time to develop, the customers grows more and more displeased: There are bugs-a-plenty on crucial mechanics, while relatively small and insignifiant functionalities are well polished and bug-free.

Getting the game as fast as possible in the hands of beta players 

The first thing to do is to involve the player as fast as possible in the game development's cycle. Doing that will significantly improve the player's sense of content and can make the game better. In the past, this kind of development wasn't practical, but, with the development of broadband, it's now possible.

Early Access

Nowadays, people talks about "Early Access". For those living under a rock, early access is a way of distributing a game in which the game itself isn't completed in a traditional sense. The customer then buys an somewhat incomplete game, of which many features will come later.

This process is by far the best idea the industry never had.

However, due to some mishandling of said practice, it's now regarded as a sing of cheapness and greed.

If the ones doing it are agile impostors, then yes. There are times where games simply gets abandoned by their maintainer. These instances gives early access some bad name. 

Early access should also be used in Agility in a form of customer collaboration. For example, one could ask a random early access player to participate in the planification of a sprint.

If the team isn't confortable with the idea, then maybe a suggestion box can be plugged directly in the backlog...

Prioritizing mechanics based on feedback

Getting feedback form customers is an important thing in Agile Methodologies. The backlog can be prioritized based on player feedback and feature requests. 

The same thing can be used on bugs. The more frequent it becomes, the more critical it becomes.

Minimal efforts of development

In most cases, the backlog should be prioritized based on business value rather that complexity. Being so, things that are developed first are important (or so the team thinks) to the game, while less important functions aren't implemented right away and have time to simmer down. Paired with early access, this becomes a quite powerful tool to test out hypothesis and experiment with mechanics.

Due to the iterative process of some methodologies, functionalities are minimal and doesn't require a whole lot of effort to develop: after all, we have no idea if a mechanic is going to be loved or hated by a player until said players plays the game.

Change prone games

Another important argument is that Agility is generally speaking change tolerant. In our case, this means that if the beta players disliked or liked a newly implemented feature, then said feature should be remove and subsequent features should also be re-evaluated.

The importance should always change based on discoveries made by the team or even the project owner. It is considered healthy for a backlog to change it's feature's priority. Otherwise, it's a bad omen...

How about me?

Agile is first and foremost a philosophy, or a way of life. Sure, it can easily be imposed to people, but it's in these situations that you get fake Agility. It should be a conviction more that a rule: a rule should be static and shouldn't change a lot. 

Agility starts with the team. If one of it's member isn't committed, it will go sour really fast.

I've seen so many times that Agility can be broken by a malicious person (a saboteur if you will). The best thing you can do to an Agile team is to be, yourself, agile.

------------------------------------------

Agility should be an integral part of game development. With Agile, you can easily prioritize mechanics that are crucial for having a fun and interesting game.