I'll prefix this post by drawing your attention, to notice, that the title of this post makes no claim to this as the best lifecycle, method, or best practice. Rather, I posit that it could be a good practice, a good or useful lifecycle. Why am I careful to couch the claim in such diffident terms? Well, the industry has, certainly in the past, often been in thrall of various experts, consultancies and others, falsely claiming that there are best practices, world leading, methods or methodologies promising certainty and control of software development.
Mark Cerny started talking about and presenting his ideas for the "METHOD" process in 2002, hoping to spark debate about process failures surrounding game development, to address in some way the human cost, the damage to people's health, of "crunch" mode management, of death march projects, of sweatshop conditions in the studio system. Interest in the Method echoed a parallel movement in software engineering that sought to shift from dominant project management paradigms (linear, stepwise and waterfall methods), that led to the Agile Manifesto and Agile Methods becoming mainstream in the software industry.
Management is the art of organisational control, of minimising risk while maximising benefit. Management methods are organisational approach for producing goods of one kind or another, they are systems of risk management. Processes, lifecycles and methodologies, are attempts to make product design and development repeatable, sustainable, to deliver value. Like many in the business, Cerny thought that games are different. A hybrid of software engineering, artistic expression, and all the creative drive to produce something that is fun, playable, enjoyable, valuable.
The METHOD is like developing two projects, back-to-back. The first version partial, incomplete, promising. The second version an evolution (perhaps even a revolution) of the first, expansive, complete, a full realisation of the game's potential. And so we organise our goals, teams and activities differently for the different stages of a game's development lifecycle. Pre-product yields a first playable version. Production delivers on that foundation, by scaling and elaborating on the original ideas. The first version is the proof of game, the 30% prototype. At this point we can put the core idea to the test. If it remains exciting, demonstrates its value, convinces us that there is a game and and audience, then yes, we go into production, we invest the 70% to bring it to production.
"Pre-production" is vastly different from "production". Likewise, the kind of feedback that is useful between the two is different. Think of a small focused audience for the pre-production effort. Think of wider more intensive play-testing (even further discovery) in the build-out and polish of the later design/development process in production. And accept that changes, even significant changes may be needed, even at, what might be thought of as, the end of the lifecycle.
Cerny's METHOD
