In the presentation, I started with describing a simple flow, such as the flow of drinks at Starbucks.
Starbuck's Kanban
If you are a 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 you to be made first. This is because the barista is working on those exclusively and the cashier can directly pour your coffee for you. Looking at the Kanban board above, my coffee goes from the "order" column to the "leave" column directly.
This benefits everyone. As I mentioned in the talk, 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, for good reason.
This is similar to the approach you might use for mixed asset types. Although every asset will have a large variation of effort needed 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 production pipeline:
A mixed asset Kanban board
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.
...and don't be surprised that as you try to improve your existing overloaded hetrogenous pipeline that the conclusion you arrive at is that maybe the assumptions of the pipeline need an overhaul!
