Yesterday I attended a webinar on Kanban provided by Janice Linden-Reed of Net Objectives. It wasn't specifically geared toward game development but I managed to come away with some useful thoughts pertinent to distributed teams. Amongst other things, Janice mentioned three principles of Kanban which I'll list shortly. For the uninitiated she provided the following definition of Kanban:

Kanban is a method to bring Lean principles into action where the goal is to deliver value, meeting the customer's needs. Build the right thing, the right way, at the right time.

Principle 1: Visibility

This is all about seeing hazards in time to react to them. A critical tool in obtaining visibility is a visual model of your work and your workflow -- the Kanban board.

Sample Kanban board, courtesy of Henrik Kniberg

In conjunction with your team's policies regarding things like prioritization and the definition of "done", your Kanban board gives you a good picture of how and when your work is being accomplished. Perhaps more importantly, it gives you a picture of where you may be encountering bottlenecks that require more attention.

Principle 2: Limit Work In Progress

Work In Progress (WIP) represents time and resources that have been spent without delivering value and should therefore be minimized. In game dev terms, you can't ship proxy models or partially implemented features. In the Kanban board above you can see some of the WIP limits imposed (red numbers): only 2 backlog items can be Selected at one time, only 3 may be in Development at one time, etc. Ms. Linden-Reed mentioned that a WIP limit is a policy and therefore requires agreement (from management and the team) and should be advertised to all involved.

Principle 3: Flow

The visualization and WIP limits come together to allow you to understand the flow of your team's work. This is analogous to what you would call velocity in Scrum -- the team's measure of productivity or work completed over time. More importantly than just Scrum velocity, though, your Kanban flow talks about where you might be seeing work clogging your pipeline. An example is that perhaps your character team is creating one fully-finished character every three weeks. That's your velocity as determined by Scrum. What you'd learn from examining your flow using Kanban, though, is that your team was able to model, texture, and rig a character in half that time, but because you only have one animator your team's productivity is held back to one character every three weeks instead of two or more in that same time period. There's a bottleneck at the animation stage. And if you have reasonable WIP limits established you'll also see that your modelers, artists, and riggers are sitting idle part of the time waiting for the animator to finish his part of the pipeline. All of that can be determined by proper visualization of flow.

What This Means To Distributed Development

In an ideal world we'd all be able to telecommute to work, dragging terabyte-sized files across our ubiquitous broadband connections and bringing together team mates from all corners of the globe. This is the dream of distributed development. One of the main roadblocks you quickly run into in the practical implementation of such an arrangement is that your designer in New York has been waiting for two hours for your programmer in California to wake up while your art director in Kiev has long gone to bed. And your QA tester in French Polynesia has ceased caring because it's already tomorrow. Everyone's on a different daily schedule you can't reconcile across that many timezones.

Well, what if you view it from the standpoint of Kanban flow? Don't get hung up on, "I delivered the model first thing Monday morning but the programmer didn't implement the feature until Tuesday so the fx couldn't be attached until Wednesday." Instead, look at the flow of the work across your Kanban board and look for bottlenecks like we saw earlier in the example of the character team. What's really important to you is the cycle time -- how long it takes work to flow all the way across the Kanban board -- and where you see the work getting clogged. Once you see that the WIP limit for the fx artist means everyone else in the system winds up sitting on their hands, then you can examine possible solutions -- determine if there are resources you can apply to the fx stage, or possibly break the dependency of the fx placement process in some way.

Admittedly, these are fairly simplistic examples. I'm not claiming to have just discovered the holy grail of telecommuting such that we can all move off to French Polynesia with our QA testers (Everyone's QA tester is in Polynesia, right? No? Just mine? Huh). But I found it helpful to think of a familiar problem with distributed development in a new way, and perhaps it will be useful to others like it has been for me. And for that I must thank Ms. Linden-Reed and her webinar on Kanban.