The manifesto for agile game development

The Agile Manifesto contains four values and twelve principles for "Agile Software Development".  It's simple yet powerful and still applies nearly 10 years later.

I've modified them slightly to better fit game development.
----
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 process and tools
• Working game over comprehensive design documentation
• Publisher collaboration over milestone 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 principles behind the Agile Manifesto:

• Highest priority is to satisfy the customer through early & continuous delivery of valuable software, assets and gameplay.
• Welcome changing requirements, even late in development. Agile processes harness change for the developer's competitive advantage. 
• Deliver working gameplay frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• Business people & 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.
• The most efficient & effective way of conveying info within a dev team is face-to-face conversation.
• A working game is the primary measure of progress.
• Agile processes promote sustainable development. The sponsors and developers should be able to maintain a constant pace indefinitely.
• Continuous attention to balanced artistic quality, technical excellence and good design enhances agility.
• Simplicity--the art of maximizing the amount of work not done—is essential.
• The best architectures, budgets, assets, 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.

Success with Agile Managers

The studios I visit that have the most success employing agile have something in common.  There is often a champion of the effort to become more agile who has a position of authority there.

Some of the things I have noticed about them are:

• They understand the principles of agile and Scrum.  They understand the source of change comes from the teams, not a process.
• They care about their people.  They want to see an end to the cycles of project madness.
• They are willing to grow trust with the teams.

Although this role isn't defined as part of an agile process, it is often is a valued one.   Lately I came across the description of a role called the "Agile Manager" in a great book by Lyssa Adkins called "Coaching Agile Teams".   In the book, she writes that an agile manager's role is:

• "Organizational change artist:  Guides the organization through agile adoption (and re-adoption).
• Boundary keeper:  Reinforces healthy role boundaries both within the team and between the team and the greater organization.
• Value maximizer: Manages the portfolio of projects like a product owner manages a portfolio of user stories, always asking what the highest business value project is now.
• Lean manager: Uses lean thinking to improve organizational flow so that the value teams deliver can be realized without delay.
• Organizational impediment remover: Finds the gritty courage it takes to remove entrenched impediments.
• Team champion:  Offers observations from the team boundary and releases the team to reach their fullest potential by truly believing they can.

The agile manager is like water--patiently, water can carve away the hardest surface, and it will always find a way to flow.  Making things flow so the team delivers again and again is an honorable (and challenging) job.  In so doing, agile managers offer their highest service to the team. "

While this role isn't unconditionally necessary for success in all cases, it is for teams that don't have the authority to overcome organizational inertia that can prevent a team from becoming agile.

Agile Development in Practice at Epic Games

Someone posted the slide deck from Epic's presentation made at a GDC tutorial a few years back.  It's brief, but it was a good presentation.

Great product owners don't count on miracles

As a CTO or Director of a game studio, one of my principles was to hire the best people possible (the most talented and committed) and trust them to do their job. 

This always got the job done, but at a cost.  Those talented people showed their commitment by working grueling long hours and wasting weeks of effort.  I'd given them plenty of rope to hang themselves from and they used it.  I expected miracles as part of planning process.

When we started using Scrum, one of the biggest challenges was the product owner role.  Casting an existing role, like a lead designer, into it wasn't enough.  The transition of thought, from executing on a detailed plan, to iterating with a critical eye on emergent value, doesn't happen overnight. 

At first, we iterated on a fixed and detailed plan.  This led to a phenomenon, described in my book, (chapter 12, Agile Design) called "parts on the garage floor".  In doing this, we produced separate polished parts of a mechanic.  However, the value of the mechanic didn't prove itself until all those parts were integrated together in a production level and demonstrated.  By the time this happened, if the value emerging wasn't good enough, it was too late to do anything about it.

The art of great product ownership requires a different mindset:

• Product owners have to trust the team to do miraculous things within a sprint, but not count on miracles beyond that.
• Product owners should not fall in love with their vision.  The must take the truth from the working game and use it to "true up" their vision.
• Product owners should demand value be added every sprint.
• Product owners must be honest and transparent with the team.  Even when it hurts.
• Product owners must take council from their domain experts and prioritize based on cost and risk as well as value.

The last point was crucial to my role as the CTO-who-depended-on-miracles.  Although I couldn't create these miracles, I certainly could foresee where they were needed.  I knew where the risks usually lay (when you are burned enough times, you eventually figure out that fire is hot).  The knowledge of risk was applied to the order of the backlog.  For example if porting our engine to the next generation platform is a major risk, we should do something about it earlier than later.  Then we won't need the miracle.

It's important for the product owner to understand risk and use it to prioritize the backlog. They are responsible for the direction of the project outside the sprints.  They have their hands on the steering wheel of the project and need to steer it in the right direction.

An iterative and incremental scale graph

The phrase "iterative and incremental" development is tossed around quite a bit without much distinction between the two.  The distinction is important for large-scale games (the kind shipped on discs).  In talks over the past few years I've shown a table that compares the differences, but on a recent flight I came up with a more graphical way to express the differences.

For such large games, there are usuall several phases of development that can't be blended perfectly even under an agile framework.  Theses are:

• Concept - Ideas are considered, prototyped, and thrown out quickly.  
• Pre-production - Ideas, winnowed through the concept phase, are built upon and refined.
• Production - Multiple levels, characters and other assets are mass-produced based on what was discovered in pre-production.

In an ideal agile project, all of these activities are mixed equally.  For such games, this proves to be impractical.  For example, if you change the jump height of the player on a platformer in the middle of level production, you may need to redo hundreds of ledges that baked in that height.  An "agilist" would recommend that you make all your ledges procedural so that you can continue to tune them, but this is often not a practical or cost effective solution.  We have to make decisions before production starts.

So here is the graph I jotted down (I love Omnisketch on the iPad):

What this communicates is the flow of development (the green line) from concept, through pre-production into production.  This flow can be for the entire game or a class of assets (such as levels).  The goals for the team and stakeholders moves from "correctness" (making the right game or asset) to that of "efficiency" (making it as low cost as possible).   Each goal guides how we do the work, either using spikes in concept development, Scrum in pre-production, or mixing in lean practices such as kanban in production.

The blue box in the lower left represents "total certainly" in our requirements and technology, which is fine if your mass-producing widgets, but is never a state we're in making games.

I find this useful in explaining that the work chooses the methods, not the other way around.