Sponsored By

New School Blues Dev. Diary #8: Project Management Part 2

In today's installment - originally dated November 7th, 2012 - YoyoBolo Games producer Mike continues his look at project management styles used when developing New School Blues. This time we take a closer look at elements of Agile management.

Yoyo Bolo, Blogger

January 25, 2013

2 Min Read

Developer Diary #8: Project Management Styles Part 2

So we know Waterfall is good at planning, but not so good with iterating.  With such a short project completion time then, we knew we couldn’t take a strict Waterfall stance on things.  While there was some design and planning typical of Waterfall based projects, as you can tell by earlier diary entries we’ve already made tons of iterations, meaning YoyoBolo’s project management style is a mix of Waterfall AND a little something called Agile.

Agile is a type of project management that works on the principle of starting with a basic design or prototype, and updating that prototype over the course of a few weeks.  Each new prototype is then refined, culminating in a finished product that reflects needed design changes.  Since more time is spent seeing the game (however primitive) in action we can make modifications and experiment much more quickly.  It allows for way more flexibility.

Agile = Ninja.  That’s how my brain works.  Don’t look for a joke here because there isn’t one, sorry.

Agile isn’t all roses though.  It’s main drawback is that it doesn’t scale well.  Let’s say you’re producing a massive project - say for example, a blockbuster movie or video game.  It would be impossible to build a prototype able to encapsulate all initial design decisions.  The project is too big to get a bite-size chunk that will truly represent the experience it intends to deliver.  Also changing any of those decisions would mean altering the structure of this massive operation.  Reorganization like that costs a lot of money and time.

Fortunately we are a small operation working on a small game, so Agile fits us just fine.  Every two weeks a prototype is due, each new prototype more polished then the last, culminating with a final version that has all assets included which is then tested so as to become the actual product shipped.  That’s it for now, but next time we’ll get more into milestones, what tasks were required, and how scheduling them in the correct order is crucial.

Read more about:

2013Blogs

About the Author(s)

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like