« Too Much Randomness? | Main | Schizoid Available on Mobile »

December 17, 2009

Comments

Drealmer

The matrix approach is what we are doing too, but inter-dependencies are getting in the way. For example a task with 2 days of coding and 5 days of art might require 1 day of coding to be done upfront so the artist can work, then 1 day to integrate the result.

We ended up dealing with little "on hold" stickers over such tasks ("half done, waiting for art"), and that looks a bit messy but I have to confess it's convenient and works quite fine for us.

Bobby Lewis

I do enterprise software development and I'm helping us move to agile/iterative. I've come up with the same thing. It's impossible for us to get business & analysts to break big use cases up to user stories that can be done in an iteration (done = requirements, design, code, test, accept). So I have user stories of dev complete => coded & unit tested and ad hoc test session with QA, qa complete => all happy path/alternate flows able to complete, if buggy, UAT, etc. and then a "home run" stretch where we retest and fix all final showstoppers.

I have to deal with resource management by type of resource as well so I need to know each team's velocity and resource needs, and we do have to do some ordering of dependencies. I think doing iterative handoffs and working these separate tasks concurrently as much as possible helps to avoid the blame game.

Clinton Keith

Jamie,

Good post!

Yes, a lot of agile texts assume that the "teams" consist of mostly programmers and that specialization slowly gives way to generalization over time (programmers do more testing, QA can review unit tests, etc).

In game development this doesn't quite apply. I spend a third of my book (~may '01) talking about team structures and how to address this for game specialists that just can't generalize that much. Things have to change.

Both commentators above point out the obvious problems: inter-dependencies and definitions of done that change as a feature emerges. Cross-discipline teams and variable "definitions of done" solve these. They also solve many of the issues of the unplanned but necessary work being done rather than slipping through the cracks because the boss didn't schedule those tasks.

Cross-discipline teams work for games in pre-production by doing better release and look-ahead planning, reorganizing between sprints and creating some shared resources/pools when necessary. Then you can measure velocity of real things (user stories). Measuring velocity of component or functional teams is useless IMO. Besides, I'd rather measure the velocity of the game, than the teams.

In production, I don't recommend the base scrum practices (http://tinyurl.com/6dtb5j). Things start to look more like functional management at that point.

Clint

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been posted. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment

Your Information

(Name is required. Email address will not be displayed with the comment.)

Jamie's Bragging Rights

  • Spider-Man 2
    The best superhero games of all time Game Informer
    Top five games of all time Yahtzee Croshaw
    Top five superhero games of all time MSNBC
    Top 100 PS2 games of all time Official Playstation 2 Magazine
    1001 Games You Must Play Before You Die Nomination for Excellence in Gameplay Engineering Academy of Interactive Arts & Sciences
  • Schizoid
    Penny Arcade PAX 10 Award
    Nominated for XBLA Best Original Game
    Nominated for XBLA Best Co-Op Game