In my last post, I talked about critical mechanics and how to use them to prioritize work. In this post I want to talk about an easy way to turn a critical mechanic into a task list using a very simple concept: the use case.
One of the hardest aspects of managing game development is prioritization. And nowhere is prioritization more difficult than in the earliest days of a project. If you don’t know what your game is, how the hell are you supposed to prioritize the work? I’ve struggled with this problem in the past and eventually ended up stealing a solution from the start-up world in the form of something I like to call “critical mechanics.”
Cost is often a significant factor in project management – which is as it should be. But, much like using weight as your only measure of fitness, monetary cost in and of itself is not sufficient for proper decision making. You also need to consider the less obvious costs (and savings) of your decisions.
One of my favorite quotes revolves around planning. It came from Helmuth Von Moltke, a 19th century German Field Marshall: “No plan survives first contact with the enemy.”1. The implication here is simple enough: the plan that makes total sense on paper quickly falls apart when confronting the entropy of reality. And yet planning is essential for getting a team moving in the right direction. As Dwight Eisenhower said, “I have found that plans are useless but planning is everything.” And thus we arrive at what I like to call the paradox of planning: planning is the act of creating something that is simultaneously infinitely valuable and completely worthless.
Here’s a question for you: is dog-fighting (the airplane variety, not the literal kind) an art or a science? It’s obviously an art, right? Two pilots, and a wide-open sky – the possibilities for maneuvers and counters are positively endless. Endless, that is, except for this funny thing called “physics”. Far from being limitless, a pilot’s options are severely restricted by his altitude, speed, weapon load, and aerodynamic characteristics. The man the world has to thank for codifying this realization is one of history’s great iconoclasts: United States Air Force pilot John Boyd. But Boyd’s gifts to the universe were not limited to the military, and one of his last major labors before he died was a paper and presentation he called “Analysis and Synthesis” or, alternatively, “Destruction and Creation.”
My friends at Black Shell Media were kinda enough to host another of my scribblings, this time on the ever-present and ever-important notion of trade-offs: how to think about them, traps to avoid when dealing with them, and why it’s so important to know yourself when faced with them. Click here to read on: On The Subject of Trade-Offs
In Part 1 and Part 2 of this series, I talked about the functional issues of scrum. In this post, I want to talk about the larger, economic problem with scrum. Namely, what was once an idea designed to support other industries has become an industry unto itself. And with that comes what economists would call a “conflict of interest.”
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.