As a developer, you’re almost perpetually flat to the boards. There is always too much to do, too many fires, too many needed fixes. You can’t create more time in the day, or more days in the week. But you can do the next-best thing: eliminate repetitive tasks using automation. Welcome to the wonderful world of jidoka.

The word “kanban” sometimes comes up in software and game development circles. But, when it does, it’s usually within the context of agile and scrum. And the interpretation of the term usually begins and ends with “It’s like scrum, but without sprints.” This is a massive oversimplification. You see, when I was a freshly minted scrum master, I often told folks that I was all about scrum, but I would happily kick it to the curb as soon as I found a better framework. Kanban is that framework.

You remember that time you plugged your HDMI cable into your PS4 upside-down and fried it’s video card? Or that time you clamped your ski-boots into your skis backwards and almost killed yourself on a black diamond slope as a result? Or that time you put a k-cup into a Keurig machine sideways an sprayed hot coffee all over the kitchen? No, you don’t. Because you can’t do any of those things. Those products are all designed so that they can only be used in the proper manner. The grooves on the HDMI connector, the specific clamps and catches on skis and boots, and the tapered design of Keurig k-cups mean that the proper application of the product is as obvious as its improper use is impossible. Welcome to the world of poka-yoke (poh-kah yo-kay).

Like this:

1947. Japan, still reeling from the Second World War, lies in economic ruin. And a little company called Toyota finds itself in a highly undesirable strategic position. It’s headquartered in a nation in tatters, and competing with companies in the world’s newest economic super-power: ‘Merca. How could it possible compete against companies with such amazing access to capital, resources and cash-rich customers? Well, necessity, as they say, is the mother of invention. And the necessities of Toyota’s strategic realities gave birth to one of the most remarkable feats of management ever achieved: the Toyota Production System. Or, more generically, “lean” development.

The Merriam-Webster dictionary defines power as (among other definitions) “possession of control, authority, or influence over others”. Nothing terribly shocking there. But it’s worth digging into how power induces that influence. There’s the obvious, overt “Do this thing because I said to do the thing.” We’re all familiar with that one. But there’s also a different form of influence that comes not from influencing people, but circumstance. And on any given day, this informal power is far more likely to cause you grief.

Like this:

The premium game model of development has a general cadence: pre-production, production, alpha, beta, and certification. There are variants of course, but that tends to be the gist of it. Alpha, beta, and cert are, of course, where we divert our attention from making features to the grueling task of fixing bugs. And, dear lord are those weeks painful. One house of cards to the next. But that’s just how it’s done, right? Yes that’s how it’s done. But it’s also incredibly inefficient. This model of delayed quality assurance means we fix bugs when it is maximally expensive to do so: at the end. After they’ve been buried under other bits of code that rely on those bugs being broken in exactly the way they are broken.

How can we wrap our heads around the chaos of game development? By understanding that the famous phrase “find the fun” implies something important: discovery. How do you manage the creative process? By acknowledging the latter word of the phrase: process. If you can understand how those terms related – and where they differ – you can appreciate something vital to effective production. That nothing we do in game development is completely devoid of process. And, if you can learn to separate the process from the discovery, then science becomes a weapon against the dark forces of development hell.

I will continue to tell anyone who will listen that Jim Collins’ Good to Great is the best business book I’ve ever read. Or, at least I will until I read something better. And in that wonderful tome, Collins’ presents a mantra: good is the enemy of great. His meaning: by being content with simply eeking along (being good), you will never take the steps necessary to be great. I totally agree with him, but I think there’s a corollary: perfection is the enemy of productivity.

This week’s post…is hosted elsewhere. I wrote a guest post for my new friends at Black Shell Media. The post, “If You Want to Lead, Know Your Values”, is about a topic near and dear to my heart. Values matter to any organization, no matter the size. They matter from a company culture standpoint, certainly. But they also matter operationally and strategically. The most successful companies in the world have well-defined corporate values. But what are their values and, more importantly, how should you pick your own? Click this link to read on!

Like this:

If you’re both the entrepreneurial type and the game developer type, then Tom Ketola is your guy. Tom and I were brothers-in-arms at Wideload Games, where we shared a love of profanity, terrible fashion sense, and a complete disregard for status quos. Tom’s career includes stints at Activision, Jaleco, Konami, and Midway. And that’s just his career in the games industry. He’s also been involved in a number of start-ups, and seen the good, the bad, and the ugly of contracts. After reading my post about conversations for studio co-founders, Tom had a, shall we say, voluminous round of comments on the nuances of shares, acceleration, and vesting. Rather than abandoning me to badly interpret his thoughts, he took pity and offered to share his experience with all of you. I leave you in his capable, knowing, manly hands. Enjoy!