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.
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.
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.
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.