In a previous article, I mentioned that a well written user story is independent – it has no dependencies. However, the majority of production is a chain of different dependencies such as creating a model, unwrapping it, and then texturing it. Asset production is actually a process that can work better in waterfall than in scrum, but since we’re talking about going from waterfall to agile, we should discuss lean and Kanban. I’ve found that agile projects that use waterfall asset production are actually just waterfall projects that use agile lingo and jargon without adhering to the actual principles of agile.

In past student projects, we’ve built our levels in such a way that we can’t see representative gameplay inside the level until the end of the semester. This has resulted in a lot of wasted time by our level designers and artists working on assets that don’t add value to the game we’re working on. Part of the problem has been developing levels before finalizing core mechanics (don’t do that), but another chunk of the problem is that we were so set in using waterfall that we were okay with not integrating all the pieces until the end of the release.

Lean thinking should help resolve this – lean is a set of principles applied to production environments where we have more certainty than in pre-production but we still want to introduce constant improvements. For example, instead of taking 12 weeks to build a level, we should build one quarter of the level in three weeks – all the most valuable art assets, textures, and music completely integrated for one quarter of the level. The faster we can see how the final version of the level will look, the more time we have to make adjustments and improvements to the level.

A Kanban board can be used to track the asset production stream. Unlike how user stories and tasks in scrum work, each asset is a card or ticket that moves from left to right as it passes through each workflow step. Each step of the workflow is assigned a capacity to communicate how many cards the people working in that stage of the workflow can handle. A stage that goes below the target number or reaches zero tasks is suffering from starvation, and those that have too many tasks are suffering from an overflow.

Lean uses two primary measures of time for production streams. Takt time is the rate of external demand for completed assets to be delivered. Cycle time is used to measure the interval of time between starting and finishing either a workflow step or the whole stream. A lot of lean and Kanban is focused on reducing takt time and improving cycle time. In the above example of breaking the level into 4 pieces, the cycle time on the level is cut to a quarter of the time by reducing the asset size. This allows the team to iterate on the level faster and results in a much more polished finished product.

Kanban can work alongside scrum by combining the two different task boards. The programmers plan their sprints using scrum and the level designers and artists plan the production of their levels using Kanban.

References

Keith, C. (2010). Agile game development with Scrum. Upper Saddle River, NJ: Addison-Wesley.