Gamasutra: The Art & Business of Making Gamesspacer
Beyond Scrum: Lean and Kanban for Game Developers
View All     RSS
September 1, 2014
arrowPress Releases
September 1, 2014
PR Newswire
View All

If you enjoy reading this site, you might also want to check out these UBM Tech sites:

Beyond Scrum: Lean and Kanban for Game Developers

November 11, 2008 Article Start Page 1 of 6 Next

[If you've discovered the value of Scrum agile development while making your game, expert Clinton Keith outlines Lean and Kanban, two ways you can be agile during all phases of the game development process.]

Many games teams that adopt Scrum quickly discover its value. The improved velocity of introducing value, or fun, to the game at a regular iterative pace shows where the project is heading and allows the team and customers to react by improving the game frequently. However teams find that when they enter production, the value of Scrum diminishes.

Many teams abandon some Scrum practices late in a project's life cycle and return to more traditional waterfall practices. They call this approach "a blend of Scrum and Waterfall". This article explains the reasoning behind this and introduces the concepts of Lean Production and Kanban as an alternative to adopting waterfall practices.

Lean and Kanban can answer the issues with Scrum that many teams face, but they don't require the team to abandon agile methods. These practices are based on real world production experiences which showed a 56% improvement in the cost of level production.

In most agile projects outside the game industry, there are no phases of development. There are no concept phases, pre-production phases or production phases. These projects start with releases, and every release delivers a version of the product to customers. Think of applications like Firefox that release a new version every month or so. Most games have a single release that requires years to achieve.

Eliminating phases is a big benefit of agile; waterfall phases such as the testing phase force the critical activity of testing to be postponed to the end of the project, where fixing bugs is the most costly. Planning phases at the start of projects attempt to create detailed knowledge about what features will be fun and the work associated in creating them. Unfortunately the best knowledge comes from execution, which is why highly detailed pre-planning fails.

For many games however, there is still a need to have phases within the game. There are two major reasons for this:

There is a minimum bar to the content being delivered regardless of the quality. Sixty-dollar games must deliver eight to 12 hours of gameplay. This represents the major portion of the cost of development and occurs after the gameplay mechanic is discovered. This requires a pre-production phase to discover fun and a production phase to mass-produce the assets for the eight to 12 hour experience.

Publishers have a portfolio-driven market model. This constrains the goals of the games that they fund. In order to gain publisher approval (which includes marketing and often franchise/IP owner approval), developers need to create a detailed concept treatment during a concept phase at the start of a project. Developers are then unable to stray too far from this vision throughout the project.

Pre-production allows more freedom to iterate on ideas and explore possibilities. During production, we are creating thousands of assets that depend on what we have discovered during pre-production. These assets create a cost barrier to change during production.

For example, consider a team in production on a platformer genre game. Platformer games (such as Nintendo's Mario series) challenge the player to develop skills to navigate treacherous environments. The production team will create hundreds of assets that depend on character movement metrics such as "how high the character can jump" or "the minimum height that the player can crawl under". Production assets depend on these metrics.

If these metrics are changed in the midst of production, it can wreak havoc. For example, if a designer changes the jump height of the character, hundreds of ledges or barriers would have to be changed. This can create a great deal of wasted effort during the most expensive phase of development.

It's critical to discover and lock those metrics during pre-production. This doesn't mean that we can't be agile during production. How we are agile does change. Instead of using an iterative and incremental process such as scrum, a more incremental process such as Lean is more applicable.

Sprints and Production

Asset creation is deterministic and sequential work that does not fit the Sprint iteration cycle very well. If we think about production as a factory assembly line, then the two to four week iteration cycle doesn't make as much sense. Factories don't empty the assembly line every four weeks and determine what to build next.

Assembly lines have things rolling off much more frequently and require incremental improvements instantaneously. The rate that completed assets roll off the line becomes the new heartbeat of the production team.

Article Start Page 1 of 6 Next

Related Jobs

Playtika Santa Monica
Playtika Santa Monica — Santa Monica, California, United States

Sr. BI Developer — Hunt Valley, Maryland, United States

Engineering Manager — Chicago, Illinois, United States

Engineering Manager — Hunt Valley, Maryland, United States

Graphics Software Engineer


Andrew Grapsas
profile image
This is a great article!

Can we have more like this, please :) Implementations of quantitative software engineering and such in the game industry are always wonderful to read.

ken sato
profile image
Nice article. It's interesting to see Kanban and LEAN practices highlighted but a caveat!--riding a horse is different from trying to saddle one. Different teams and groups define "waste" and "optimal" in creative ways. Changing some practices can be a considerable goal.

Clinton Keith
profile image
Andrew - Thanks!

Ken - Agreed! Continuous improvement is a cultural change. Sometimes you can't even get near enough to the horse to saddle it;)

Tommy - I'll try to answer your questions:

Preproduction is partly about designing the value stream that will produce the assets. You build your heijunka board based on the value stream. This can transition at the end of a sprint.

For this example, the script referred to the story since it came before even concept art. I should have clarified that!

Ideally you develop tech that production is dependent upon before you enter production. If you have programmers within the same Lean team, they can work with their own Scrum task board, but they mainly support the production team. Outside the team, they can still be doing standard Scrum Sprints.

Hope that helped...thanks for the great questions and comments!

Vladimir Neskovic
profile image
What an inventive way of "remixing" Scrum with Lean. I would have never thought that Lean's flow improvements and reducing waste philosophy would fit in SW or game development. I would also expect lots of complex optimization problems on setting the proper takt vs. resources utilization, but any improvement of the production time is welcomed. Also i would speculate on the volatility of the takt time method. If some of the estimations are not proper, which happens usually in our industry nevertheless the good prototyping in pre-production, the balance of the workflow is immediately broken. This is why i would use Lean in Scrum with experienced team and in sequels or ad-ons where the probabilities of the wrong estimations are much smaller.

Clinton Keith
profile image

It's been used in a wide variety of projects. Time-boxing tends to allow for smoothing over volatility a bit, but you are right that volatility can occur. It can also occur on scheduled tasks as well, correct? Isn't it better to deal with it using an empirical pull system?

Also I didn't spend a lot of time on reducing other wastes in the value stream that is also quite effective.


Saul Gonzalez
profile image
I know this is nitpicking that has nothing to do with the meat of the article, but I'd like to point out that in everyday Japanese "kanban" (where kan=look over, ban=plank) means signboard, like those used in advertising. The "Kanban" from Lean Manufacturing is derived from this word.

Mark Harris
profile image
I've actually been really impressed with the amount of production articles I've seen on Gamasutra. Software development in general, and the game industry in particular, have suffered from a lack of project management. I'm glad you've brought some of the lessons from manufacturing managed processes along with you, as developing large software products IS a manufacturing process. While there are many factors that go into creating a quality software product, instituting an efficient and managed process can eliminate a good number of pitfalls and result in higher quality products with much lower costs. I think we can all agree that producing less shovelware is good for the industry and the consumer.

Clinton, keep the articles coming!

Tom Mortensen
profile image
Fantastic article, Clinton!

In my head, Iíve been battling with the process conflicts of applying Agile to games development for years. Finally, it seems like someone is getting a good stab at the whole thing. A lot of pieces have fallen into place for me over the last couple of days, and reading this article certainly helped. I also read your blog on Alan Cooperís Agile 2008 keynote. Iíve been a big Cooper fan ever since I first came in contact with Interaction Design, and that he now is focusing some energy on our industry, is really good news.

As I see it, one of the most fundamental issues still remains: Often we donít know if what weíre building will really work until we can experience it in a greater context. Most elements of traditionally software is successful if itís technically sound and user friendly, but with games we also have to get the fuzzy and elusive elements of aesthetics and gameplay right. Often that require us to go back and change things over and over again even when weíre in production. Sometimes that far exceeds what we can comfortable label as polish and tuning.

To avoid excessive waste, that would logically call for a more iterative process. I guess the confidence in our level designs could maybe be improved if they were mocked up or prototyped in pre-production. Expanding this part of the project, however, comes with itís own drawbacks and might not even be possible. Another option would be to add some sort of flexibility to the suggested production process, but I canít really see how to do that without messing up the fine-tuned Lean process.

Anyway, great read. I need to think some more about it.

Tom Mortensen
profile image
Ahh... just looking through Cooper's actual slides and notes from the keynote. I realise itís about software development in general, and it was you that applied the games development perspective. I still wish Cooper would join the fun, though :)

Dennis Crow
profile image
Great article Clinton,

How would you deal with using Kanban methods for dealing with multiple software projects that change regularly? Is there any way a more dynamic team can combine Scrum with Kanban to identify waste?

Clinton Keith
profile image

>Another option would be to add some sort of flexibility to the suggested

>production process, but I canít really see how to do that without messing

>up the fine-tuned Lean process.

We didn't see that. The one week takt time allowed some iteration within the co-located team.


That's a good question. I know that people are dealing with this in the Kanban space. I don't quite believe that Kanban is better for more iterative software development, but not everyone agrees.


William Conroy
profile image
This is great, I've been thinking about a similar board as of late in our project. Alas, I don't have the time to commit due to a busy pipeline :(

A couple of things:

- The example in the article suggests some kind of hard requirement from left to right, whereas often there are 'branches' to the pipeline, where multiple streams of work can be carried out at once. How do you elegantly describe these scenarios in diagram and 'signal card' form?

- How do you introduce elements such as qa passes, or external feedback passes (say in a outsourcing context). Do you add extra loops into the board? Do you feed 'failed' stuff back into the beginning?

Clinton Keith
profile image

Branches and loops can be represented in the vertical space of the kanban board. You can also draw lines for the handoffs on the board as well. These are all implied in the simple example from the article.