Posted tagged ‘development’

Complicated vs. Complex: Why Game Development is Hard

April 11, 2015

Developing a game is difficult, to put it mildly. And it never quite comes out the way you plan. Despite this, many developers and (especially) project managers — smart, talented, ferociously hard-working people — continue to believe that somehow this time they’ll make the right schedule and be able to predict months in advance when their game will launch.

This never works (okay, unless you’re just copying someone else’s game). And yet, project leaders continue to create Gantt charts of doom, or to try out one production methodology or another in hopes of making game development predictable. As one pervasive example, Agile/Scrum has long been touted as the way to successfully develop a game. Unfortunately, as some have long suspected and recent data has shown, using Agile isn’t a predictor of game development success (but see below). In fact it scores about as well as using a traditional (and long-reviled) Waterfall process!

Okay, so making a game is hard. Really hard. We all know that. But why? And what can we do about it? (more…)

Advertisement

Adding Debt to your Daily Scrum

April 7, 2015

Debt in a project (technical or otherwise) is something no one wants in a project.  But I believe it belongs in every Daily Scrum / Stand-up meeting.

Everyone who uses Agile/Scrum knows the the three big questions used in a Daily Scrum or Stand-up meeting:

  • What did I finish yesterday?
  • What am I working on today?
  • What is blocking my progress?

These questions are meant to be the daily pulse of the project. Among other things, this short meeting is how you (as project leader or Scrum master) spot the trouble spots before they become crises.

But a few years ago I noticed — after being stung by it a few times — that there was a question missing. So I’ve added a fourth question that everyone is expected to answer in daily Standups:

  • What debt have I incurred?

I added this to our meetings after noticing that sometimes a task would be called “finished,” would be moved to testing and then acceptance — only to find out later that, in order to make the original time assessment and get the task (and user story/feature) into the current Sprint, someone had to cut corners: some temporary art was used, a bit of unfinished design was papered over, or a single-use function was quickly created, knowing that it would have to be refactored later.

Ideally when this happens, a new task should be added to the backlog to be addressed later — that would keep the debt transparent. But in my experience this often does not happen, whether due to the intense focus in mid-Sprint or the reluctance of someone to point out that their task isn’t really finished.

So, I started including the debt question to be answered by everyone every day. It takes only a moment to answer, so it’s not in danger of burdening the brevity of the meeting. It’s also not always the most comfortable question to answer — no one likes to admit that they had to take a shortcut that’s going to need attention later. But it also gives team members a natural outlet that’s just part of the process to bring this up. Doing so gives everyone a more accurate picture of what actually remains to be done, and just as importantly, helps refine future task scheduling. Most of all, it prevents the dread of instabilities or unfinished bits lurking in the shadows as you come to a release.

Finally, having an open understanding of any debt incurred helps you as a manager spot those who are making a habit of cutting corners and help them to move past it. Left unaddressed, this practice can ultimately undermine the product, making it less robust or require a surprising amount of time in “bug fixing” (when a lot of debt is often silently taken care of). Helping those on your team estimate tasks more effectively, not cut corners — or do so judiciously and consciously — and ultimately make a better, more stable product is good for everyone. Even if it can cause a bit of squirming in a daily meeting.

The Next Book You Should Read

April 6, 2015

This is a post I’ve been meaning to write for a long time, and its time may have passed. But I keep finding people who haven’t read Ed Catmull’s Creativity, Inc.. If you’re someone who leads creative teams (or is just interested in how this is done), this book should be next on your list. In fact, set aside whatever management book you’re reading now and go get this one. It’ll be better.

Ed Catmull is the President of Pixar, and according to many is largely responsible for its continued success in delivering movie after movie that are both commercial and creative hits. In this book he goes through war stories and “lessons learned” that will be familiar to anyone who’s ever read a leadership or management book. But Catmull adds to this his unique perspective applicable to leading teams that have to be both outstandingly creative and also commercially successful. How to do this is, to point a finer point on it, something that the games industry has yet to figure out.

Among the worthwhile points made in the book are some specific practices that I believe can benefit any creative team, if their management will implement them — and stick to them. The last chapter (actually after the Afterword), “Starting Points,” offers “Thoughts for Managing a Creative Culture.” any of which are useful on their own. You’ve no doubt seen many of these before, but reading about them in context and in actual use at Pixar gives them new life.

The Braintrust
To me the single best practice that I got out of this book was the use and structure of Pixar’s Braintrust. This is a group of people — all experienced enough to get out of their own way and act in a service position rather than feeding their own egos — who review and help develop each of their movies from initial pitch to final cut.

But here’s the significant thing: this isn’t an “executive review committee” that each director comes before as a supplicant, waiting for approval or the ax to fall. It’s not where business decisions are made. It’s not even where creative decisions are made. The Braintrust reviews a movie in progress (and they must be seasoned enough to see past rough cuts) and calls out issues they see. But then they don’t try to fix them. They may not even offer solutions. The director is responsible for taking the feedback and figuring out how best to address it. There’s a story in the book, for example, about a problematic scene in The Incredibles (p102-103). The group discussed the problem, and then later the director returned with a solution that none of them had foreseen — or that anyone would have seen in a typical “management” meeting.

Feeding the Beast and nurturing Ugly Babies
Another key idea that resonates well with any creative team is that of the “Ugly Baby” vs. “the Beast” (pp 129-138).  “The Beast” is that which must be fed — the never-ending pressure and need for commercially viable products. “You’ve got to to feed the beast.” We’ve either all heard that or lived it, often sacrificing creativity and originality to do so — which is how Disney churned out a series of lackluster movies years ago, and how many game studios continue to pump out a seemingly unending array of uninspiring games. The “ugly baby” is a reference to how almost any new idea is at first “awkward and unformed, vulnerable and incomplete.” As Catmull says, these need to be nurtured, but this is in opposition to the needs of the Beast. Which is why we in games so often kill our ugly babies.

As one example, he details the development of the movie Up. The movie as pitched was nothing like it is now: the story originally began with a king and his two sons living in a castle in the sky. The princes, who hate each other, fall off the cloud and land on earth. There they have to learn the lessons of life, and in the process are befriended by a strange tall bird.

As you can imagine, the movie went through many, many iterations to get from there to the masterpiece we have today. In fact, Catmull says, the only two things to survive the entire process are the title and the tall bird. The director, Pete Docter, went through revision after revision, eventually converging on the story and world he and his team wanted to bring to light. Docter’s comments in the book on the difficulty and necessity of failure in finding the right story are illuminating.

I could go on, but I’ll end this with one final quote from the book about failure and the desire management often has to control everything in the creative process:

Whether you’re coming up with a fashion line or an ad campaign or a car design, the creative process is an expensive undertaking, and blind alleys and unforeseen snafus inevitably drive up your costs. The stakes are so high, and the crises that pop up can be so unpredictable, that we try to exert control. the potential cost of failure appears far more damaging than that of micromanaging. But if we shun such necessary investment — tightening up controls because we fear the risk of being exposed for having made a bad bet — we become the kind of rigid thinkers and managers who impede creativity.

If you are someone who leads creative teams, or who ever hopes to do so, I cannot recommend this book highly enough. And by the looks of the mountain of creatively vacant products our industry (and others like it) continues to drive to the market day after day, the wisdom accumulated by Catmull and Pixar is something we desperately need.