A few years ago, I pulled into one of the many local Starbucks, like I did everyday. But on this day, the world changed for me.
We had been applying Scrum successfully on our games for a while, but we had a problem with applying it during production.
Often, games go through at least two phases before they launch. One is pre-production, where the core gameplay features and engine are developed.
The second is production, where the hours of gameplay content (levels, characters, story) are developed using those features and technology.
As much as we tried to be agile, we couldn’t eliminate that separation of phases.
The problems were that during production there is more of a flow of handoffs from one discipline to the other, and large assets, such as levels, took far longer than a single sprint to complete.
This led to a lot of unfinished work at the end of every sprint and bottlenecks between the handoffs.
Now, if you are a straight-coffee drinker who frequents Starbucks, like me, you probably appreciate that you don't have to wait for all the lattes, cappuccinos, etc. ordered ahead of your cup of coffee to be made first.
The barista works on those exclusively and the cashier can directly pour your coffee for you.
That day at Starbucks, the light bulb turned on.
I thought, maybe we can learn something from this. A bit of Googling showed that Starbucks was applying a practice called Kanban.
Kanban roughly translates to “signal card” in Japanese. It’s a set of practices that focuses on the flow of work and uses the state of the work in progress to signal to the people doing the work what they should do.
At Starbucks, the empty coffee cups, marked with your misspelled name and order details are the Kanban. Based on how many there are between the cashier and barista, this informs them of what they should do next.
Looking at the Kanban board above, my coffee goes from the "order" column to the "leave" column directly.
Based on the size of the line, the barista and cashier might help one another out. If the line is long and the barista has nothing to do, they’ll ask people in line what drink they want and start making that before the cashier takes their order.
Conversely if the line empties, but there is a backlog of unfinished drinks, the cashier will join the barista in making drinks.
This benefits everyone. A key metric for Starbucks is the customer cycle time: the amount of time it takes between walking in the door and when you walk out with your drink.
The critical path for coffee drinkers and latte drinkers isn't the same, but it isn't entirely separate; much as I personally would enjoy it, there is no separate cashier line for coffee drinkers.
Starbucks has chosen not to optimize specifically for us straight-coffee drinkers for good reason.
This is similar to the approach you might use for asset types. Although every asset will have a large variation of effort needed (like that between coffee and a latte) and partially separate paths, measuring every asset's cycle time will still give us valuable information.
The goal isn't to achieve a uniform cycle time for all assets, just as people who order lattes should expect to wait longer at Starbucks than us super-efficient coffee drinkers.
Let's look at the Kanban board that shows various assets going through a game asset production pipeline:
This board includes assets that might need particle FX or animation applied to them, or neither. The important principles apply.
We're going to measure the throughput and limit the work-in-progress (WiP) regardless of which steps are taken. Some assets will skip some steps like me skipping the barista.
Doing this can improve the entire system. As a coffee drinker, I don't care how quickly the barista can make a latte, but I greatly appreciate when the under-tasked barista helps fill coffee orders.
This can happen in an asset production pipeline as well. As we measure throughput, we can create such policies in a production pipeline: Starbucks has far shorter coffee cycle times than barista-drink cycle times and that is fine for everyone.
The key is to measure throughput for different asset classes and explore where and when improvements for classes can improve their cycle time without impacting the other classes.
Most production pipelines are far more complex than this, but the same principles apply. Start by simply modeling what you're doing now. Then measure throughput and reduce WiP.