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.