Monday, November 25, 2013

An Introduction to Lean for Game Development

What is Lean?
There are many definitions of lean and many different applications of it (the main being manufacturing and software development).   Here are three I’ve seen and liked:
  • It’s a way of building complicated stuff
  • It’s a system-driven approach to applying empirical process control
  • It’s a production practice that considers the expenditure of resources for any goal other than the creation of value for the end customer to be wasteful, and thus a target for elimination.
Lean practices, including Kanban, offer improved approaches to doing some work better than a pure approach using an agile framework, such as Scrum.

Why Use Lean?
The work better suited to lean:
  • Is more predictable in workflow and size
  • Requires less exploration and iteration
  • Has a chain of specialist work and handoffs that last longer than a typical sprint to produce something of value.
Work, such as level and character production, are good candidates for lean.  This is opposed to the work done in pre-production to explore what makes levels and characters fun and good looking, which is better suited to the cross-discipline swarming and iteration of a sprint.  The sprint time-box is great for limiting explorations to reasonable chunks of time and cost that can be used to inspect and adapt the game and the plan for it.  This time-boxed approach doesn’t fit as well with more predictable flows of work that have their own cadence, such as levels that might take a month or more to complete or bug fixes to an MMO that need to be tested and deployed daily.

What does Lean look like and how is it different from Scrum?
The major visible difference with lean is how the work is managed by the team.  For example, using Kanban practices, you’ll see task boards that are more detailed and have more policies to manage them.  A typical Kanban board for level production might look like this:

Each column represents discrete stages of workflow from backlog to done.  The numbers at each stage are called work-in-progress limits.  This setup has several benefits:
  • The work-in-progress limits increase the speed in which assets flow through.
  • The columns quickly show when the flow is piling up too much or if there is something blocking the flow that needs to be dealt with.
  • It allows improvements to be seen in the flow soon after they are introduced.
  • It gives everyone on the team instantaneous feedback on the big and small view of the work.
Rather than measuring how much is completed every sprint, lean practices measure the amount of time each asset or feature takes, from concept to done.  This time, called the cycle time, becomes the primary metric used to evaluate the pace of improvements and the date when the work is forecast to be completed.

Most studios using lean apply a combination of Scrum and Kanban practices commonly called Scrumban.  This typically means that the roles and most practices of Scrum are preserved.  The main difference is that instead of having a Scrum sprint, where the planning and review of a number of assets or features are done at a fixed time, Kanban planning and review is done on demand.  Teams will often still want to hold a stakeholder review of what was completed since the last review and hold a team retrospective.  This is referred to as a cadence and is usually set at two or three weeks.

Lean practices work best when there is more predictability and flow in the work.  Scrum and lean share a similar mindset of transparency, inspect-and-adapt practices and a focus on continuous improvement.  They describe different practices and tools that studios find complementary and ultimately customize as teams find better ways to work and make games.

Article on Kanban and asset creation
Chapter 7 in my book Agile Game Development with Scrum goes into more detail.