In the Part 1 of “The Fancy Mess of Scrum”, I talked about the flawed intuition behind sprints: how they batch work, obfuscate inefficiencies, and are superfluous in terms of extrinsic motivation. In this post I want to delve deeper into higher order negative externalities that sprints spawn – the consequences of the consequences.
In a day and age where new titles hit the market on a daily basis, being able to stand out from the crowd is super important. In 2016, 4,207 games launched on Steam. Steam doesn’t let you launch games on weekends, so that’s approximately 16 games per day. How do you differentiate yourself from the 15 other games launching at the same time as yours?
Back in the heady days of 2010, I was a newly minted scrum master, fresh off my training seminar. I was excited by scrum’s potential, but I also took care to maintain some agnosticism. I always told people that scrum was the best production framework I’d seen, but that I would happily kick it to the curb as soon as I found something better. With several more years of experience under my belt, I’ve come to the conclusion that there are, in fact, better ways of managing development. And with that understanding came the further realization that I want to leave scrum behind.
GDC 2017 was my first GDC ever. So, I figured “Why not be an asshole about it?” and signed up to give two presentations. 6’ish months later I found myself at GDC, sweating bullets and shitting bricks. I should also mention that the longest presentation I’d ever given was about 10 minutes, and had signed up for a total of 90 minutes of speaking time. Anyhoo, both presentations went well and nobody died. And then, a month and half’ish later, my compiled speaker feedback arrived. It was largely positive. But, of course, there were a few people (4 in each session, based on the reviews) who took umbrage with ol’ Justy. And some of the negative comments bothered me. Not because people disagreed with me (that’s to be expected, after all) but because I couldn’t respond. But then I realized that not only could I respond (having a blog and[…]
This post is about an empirical issue: the economic cost of being an auteur. When I originally posted this entry on Gamasutra back in 2014 it was not without its detractors. David Jaffe even dropped a line on it, saying he thought it was neat, while simultaneously implying that I was full of shit. Nonetheless, in retrospect, I still feel this idea is worth considering in an industry like ours, one that consists of both public personas and massive-team-based endeavors.
On January 28th, 1986, seven astronauts boarded the Challenger for its tenth launch into space. Its previous missions had included the first space walk and, at various times, the first American woman, African-American, Canadian and Dutchman in space. 73 seconds after lift-off, the Challenger broke apart, killing the entire crew. Why? Because the fuel tank exploded. So, the solution, of course, is to send the next shuttle up with a fuel tank that doesn’t explode, right? Only if you assume that the exploding fuel tank was a 100% isolated incident, completely unrelated to any other events. If that sounds fishy to you, it should. And this is where root cause analysis comes into play, a practice colloquially known as “the five whys”.
A commonly held belief is that it’s best to batch work – to handle similar tasks in large, consolidated chunks. The notion makes intuitive sense. It allows you to focus on one activity at a time and avoid so-called switching costs of switching activities. But as with so many other instances of unverified intuition, this particular notion is flat-out wrong. Batching may avoid switching costs, but it greatly protracts flow time, which, in the long run, can end up being far more expensive. Which is why the Toyota Production System introduced the concept of heijunka – “leveling”.
One of the more interesting characters I’ve encountered in my wanderings through the internet is a man by the name of Jocko Willink. He’s the author of Extreme Ownership and a business consultant. Oh, and an ex-Navy SEAL and a black-belt in jiu-jitsu. So, the man knows a thing or two about getting shit done under arduous circumstances. And his personal mantra is “Discipline equals freedom.” And the more I study operation science and the more I learn about software development, the more I see his point. So, in this post, I’m going to walk you through a multi-step process for testing code and how a little QA discipline can avail a lot of freedom.
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.