Daily news, dev blogs, and stories from Game Developer straight to your inbox
Sponsored By
Featured Blog | This community-written post highlights the best of what the game industry has to offer. Read more like it on the Game Developer Blogs.
The Agile Principles of Game Design/Development
The Agile Manifesto was written sometime ago to promote a new customer focused, iterative way of working that empowers the people building software. In this blog we take a look at a games focused rewrite in order to better understand how it may help us.
6 Min Read
This was original posted on my personal blog: meheleventyone.com
Let’s face it the Agile Manifesto is very much Software Engineer focused. It's not meant to be but that result is a consequence of the backgrounds of the people that wrote it. The principles also do a poor job of explaining why and how they embody the manifesto values. This can make it somewhat hard to frame in your own context. This redrafting is a bit of an experiment in changing the principles to make sense for game design/development. I’ll highlight the changes I made in bold. The original Agile Manifesto can be found here.
First the values themselves:
We are uncovering better ways of developing games by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Playable games over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more.
The first thing to read is the very last sentence. A lot of people read the manifesto and mistakenly assume that there should be no process and no documentation. The point of the manifesto is that those things are necessary to a degree but should not be the focus of production. Making them a focus often leads to negative impacts on the game you're trying to create.
Why a playable game rather than comprehensive documentation? What about the Design Treatment, the Preliminary Design, the Final Design and all the other ancillary documentation you might produce? The simple fact is that the value of an idea for a game is much better expressed as a game that you can play rather than abstracted into a document. A document is open to interpretation in a manner that an actual demonstrable game isn’t which means that two people can have wildly different ideas about how the end product might turn out without either of them actually being wrong. A design expressed as documentation and a tangible, playable product is there to be critiqued much more directly with far less ambiguity. Further generating comprehensive documentation rather than a product is a big waste of time as we know that we will be making changes as we go along and a big list of things to implement before the game is ‘finished’ often delays critical iteration.
I re-phrased the Agile Principles as:
We follow these principles:
Our highest priority is to satisfy the customer through early and continuous delivery of a quality game experience. This provides us with the best and most direct feedback so as to shape out product direction. It also means our game is continuously in a shippable state. The value of a game is captured in the quality of the experience.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. Late changes are a reality of the business.
Deliver a playable game frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Frequently providing a playable game means frequent feedback from stakeholders, playtesters and colleagues. It is the engine of iteration.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Autonomy, mastery and purpose are the key motivators.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
A playable game is the primary measure of progress. We are making a game, if the game is not changing we are not working on it. A feature designed on paper is not a feature that is playable.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity–the art of maximizing the amount of work not done–is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
The principles were not originally numbered but I’ve done so to keep the discussion brief, it’s not a statement on which of the principles are more important than the others. Never the less there are a few of the principles that are good to call out in groups.
Process Improvement: Twelve represents the engine of process improvement within the agile framework, it’s taking an iterative and evidence based approach to improving the working practices of a team with the rest of the principles representing the yardstick by which to measure them.
Game Improvement: Seven details the key indicator of progress. The state of the game itself. Combined with Three and One it provides the engine for evaluating and iterating on the game.
The Team: Five and Eleven detail who the team is and how they should be managed.
Mindset: Eight, Nine and Ten frame the mindset required to work with an agile process with One as the goal.
Working Practices: Two, Four and Six detail important working practices that are part of the reality of working on commercial products with many people.
The entire point of the Agile Manifesto is to define a new way of working that is customer focused, iterative and concentrates on making the best product possible by empowering the people that make it. Hopefully this re-write clarifies how this approach fits game design/development and gives people a good starting point for defining their own processes.
Read more about:
Featured BlogsAbout the Author(s)
You May Also Like
