IGDA Forum: Torpex's Fristrom On How Not To Schedule A Game Project

At the IGDA Leadership Forum, Torpex Games' technical director Jamie Fristrom gave a talk entitled "How Not To Schedule a Game Project" that ended up a little tongue-in-cheek. He recounted how he had been nominated for the task when reflecting on how much he dislikes these sorts of talks, during the Leadership Forum's planning stages. The progression of Schizoid, Torpex's first project, was the catalyst for much the advice in the talk. According to Fristrom, "I am a scheduling geek. I've always actually liked to schedule stuff. I love reading books on how to schedule. I love going to talks on how to schedule. I love how they are all of these optimistic fairy tales. I take this advice and I try to use it in my own projects and it never comes out that way. I try to apply these methods and I still miss my ship dates. Turns out there is no silver bullet." The Three Key Elements Fristrom opened up the floor to a hands-up poll, asking how many of the audience use what methods for scheduling their projects. How many use MS Project? How many use auto-leveling to find the project's critical path? How many use Excel? How many use something simpler, like file cards, paper or corkboards? Someone shouted out that Hansoft -- itself a sponsor of the talks -- has a good solution, but Fristrom admitted that he hadn't had a chance to try it yet. According to Fristrom, Hansoft aside, "There's a variety of methods you can use at various degrees of rigor to schedule your project... none of them work." All the same, Fristrom believes that there are three key elements for scheduling a project: beak down tasks into granular chunks, have people who will do the work make the time estimates, and track progress and feed that back into the system. Fristrom dovetailed into a list of projects he's worked on before -- including high-profile games, such as Spider-Man 2 -- many of which got canceled, went over budget, slipped the schedule, or lost features. "The only slam dunk, unqualified success game that I've lead is Tony Hawk 2 Dreamcast. It was both an iteration and a port... the two kinds of easiest game development you can do. The only thing I've managed to slam dunk. If I thought I was the only one with this problem I'd have quit by now." Question Of The Day Fristrom then asked the audience who had delivered a game "on time, on budget, 90% on Game Rankings, to original spec?" The audience just laughed. "Why is it hard for us? Theoretically we're just being asked to guess how much time and money a certain set of tasks is going to take. We should be wrong half the time instead of 99% of the time!" Fristrom brought up two quotes that get mentioned when it comes to game development schedules. He started with Parkinson's postulate: "Work expands to fill the time allotted for it" and Hofstadter's Law, "It always takes longer than you expect even when you take into account Hofstadter's Law." His reaction? "The fundamental theory behind these quotes is that we're lazy, right? We're always surfing the web and hanging out by the water cooler. This enrages me. Everybody on our team busts our ass. We're not slacking!" Before moving into a discussion of the breakdown of scheduling on Schizoid, he offered this summation: "Maybe there's a way to fix it... I don't know what that is yet, but I have some insights to show you." Scheduling Schizoid And Cutting Drag On Schizoid, "At first we did awesome -- we had a straight trajectory that said we'll finish around April this year. To be safe we said 'August' to Microsoft... we hit a speedbump and another and another..." Fristrom recounted how the team hit a lot of bugs when it came to optimizing the game. "Now I'm starting to wonder... the agile [software development] people talk about velocity. Is velocity a constant? Maybe it's not a constant." Terming scheduling problems that pop up "werewolves", Fristrom continued, "This is what I've been seeing on every project I've worked on, but it's never been made clear for me before -- it took a small team and this scheduling method. Every werewolf I've dealt with is, oh yeah, it's great at first but then we slow down for some reason. It's drag." Fristrom defined "drag" as "the retarding force exerted on a moving body by a fluid medium such as air or water." "I think drag applies to almost all projects. Some of it is imaginary drag -- it's not literal drag, it just seems like drag based on how we schedule. We base our early estimates on certain factors but there are unknowns we don't factor. They will show up on the chart as those werewolf points." "Most of the underestimation is due to stuff we forgot. In games we tend to forget... every game has new challenges, every game has new things to overcome. The place where this becomes a problem is because it's not till the end of the project till we find out what these things are." According to Fristrom, as development moves forward, returns on things like bugfixes diminish. "Those first days are when you take all the stupid code out. But when you get down to the bottom, it's like 'Crap, we're going to have to totally rewrite our architecture to get any gains!' At the end of your project you're tracking your bugs... as you get near the end you've got not that many needles and a very large haystack." Drag gets increased, according to Fristrom, thanks to the pull of the work you've already completed. Uncaught bugs and issues in old code, new features that have to work with old ones, turnaround times increasing as the project gets longer, and bugs being harder to find and fix also contribute. "Any change costs more the later in the project you get to -- it doesn't matter if it's planned or not. You have to do the tasks in your project in some order. The last task you put in has to work with all of the old features you've already put in." The Band-Aid Approach Fristrom's skepticism about finding solutions to this problem shone through again when he referred to his suggestions as "Band-Aids." "Most of us still have to make that tradeoff when we realize we're not going to make it on time, to cut bad stuff, to tell people we made deals and contracts with that we're going to slip. The sooner we realize we're late the better -- just getting the slippage visible earlier is better." On Spider-Man 2, Fristrom tried tracking dependencies in MS Project, but ended up frustrated and giving up. "Instead of tracking dependencies, try to eliminate them. I think a flexible team can work around dependency problems as they come up. Knowing that a problematic dependency is on its way is not that big of a deal. 'I need a guy so I can do the AI programming.' Here's a flat-shaded 200 polygon guy, go to town." Fristrom advises to use placeholders or even an older engine -- just make sure data is compatible. Speaking to publishers in the audience, Fristrom said, "You guys won't fund a game if there's no list of milestones, I understand that..." All the same, Fristrom seemed to think milestones lead to deception and wasted work. "I especially hate the '20 game levels due by this date', 'cause you know what happens? You take 10 levels and cut them in half... you waste a week and nobody wins. Why do we need these letter-of-the-law milestones? Publishers have a lot of leverage already -- they can cancel a project pretty much anytime they want." Buffers And Required Reading Speaking on the concept of a contingency buffer, according to Fristrom, on Schizoid, "We needed at least a 150% contingency buffer to ship on time. Back in the Spider-Man days I used to schedule 100% contingency because I could. But no independent publisher [can]... if you publisher guys got that as a line item you'd never let that slide!" When it comes to scheduling, Fristrom suggests some conventional wisdom: "Double all your estimates for the publisher but internally you need to be trying to hit your undoubled estimates." The problem? "If you're just barely making it, you're already in trouble -- you need to go to the publisher and get the stinky fish on the table and say 'we underestimated'." According to Fristrom, these books are required reading for anyone scheduling a game project: Mike Cohn's Agile Estimating and Planning; Joel Spolsky's Painless Software Schedules; Eric Bethke's Game Development and Production; Eliyahu M. Goldratt's Critical Chain, and Tom DeMarco's Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency. Fristrom almost mentioned Fristrom's Law -- one he coined on his blog, which you can find here. Rather than discussing it, he enjoined the audience to "Google it to find the math I used, and you can use the formula to fit your experience." He clearly wants comments and discussion, too -- so have at it!