Let’s face it the Agile Manifesto is very Software Engineer focused. I’m not sure it’s meant to be but it’s a consequence of the background of the people that wrote it. The principles also explain what but not really why or how the principles directly interact with the manifesto values. It’s also a bit hard to frame in your own context sometimes. This is a bit of an experiment in re-drafting the principles to make sense for game design/development. I’ll highlight the changes I make in bold. The original Agile Manifesto which 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 plan
That 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. Lots of people read the manifesto and 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 as they have a tendency to take over and work against the primary goal of making a particular product.
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.