« Manager In A Strange Land: Theory Of Drag, Part 2 | Main | Manager In A Strange Land: Theory of Drag Part 3 »

January 12, 2008

Comments

Clinton Keith

The thing I love about using velocity tracking is the visibility it gives you. Too many PMs rely on their predictions and ignore what and why they are tracking deviation.

When you track empirical data you start to see trends (as you are posting about) and you start to develop insights into the true cause. The causes are nothing new, but the metrics give you real tools to address them as you have never been able to.

I wrote about the velocity drag issue over release cycles in this post:
http://www.agilegamedevelopment.com/2006/12/debt-and-effects-on-releases.html

I think we agree on this.

Clint

Clinton Keith

For some reason my link was clipped by typepad.

I chopped it into 2 lines:

http://www.agilegamedevelopment.com/2006/12/
debt-and-effects-on-releases.html

Chris Busse

I suppose ultimately my question/point might be could you scale back feature creep to attain a more solid end. But, honestly, I was curious about the data. I think it's an interesting concept and wanted to know more about what you're/we're seeing with your data.

Jake Simpson

Actually Mate, what I meant was that I see a sine wave superimposed over the curve you see there. Like a RF modulation - the overall curve I see is that same as you get, but it jitters up and down along that curve which is the sine wave I am talking about. The jitters are larger or smaller depending on who you are and the amount of discrepency about your task prediction but the are there - it's not *just* about in accurate prediction of time taken, but about ability and desire to actually do it.

Does that make sense?

Simon Cooke

I think I'm with Jake on this one... the whole system is somewhat fractal; for any given task, you'll see that sinewave, but it disappears on the scale of a day or a week - no one tracks closely enough to see it.

Over the course of a month (for a big, largely undefined task like a port), you get the sinewave much more visibly. If your tasks are always modular enough though you end up with the aforementioned situation where it disappears into your noise again.

Scale up a bit more, and on the milestone level, you're going to get the same thing, with the peak of the activity right before the milestone, and a drop off afterwards. And again, look at the entire project as a whole, and on that scale, you should see pretty much the same thing.

Annoying, huh?

As for being more waterfally - I'd agree with that. My style is to carefully architect stuff, do it, and hopefully only have to revisit it for minor tweaks. Most people I work with are more iterative/agile. The difference being, sure, it'll take me 3 times longer to check the first set of code in, but you rarely need to revisit it. The bugs tend to be minor, the additional feature work close to non-existent.

I can't recommend it as a way of working for most people though - it scares managers (because it means you go dark for longer periods), it's not as self-sustaining (because you don't have that instant gratification quality of checking code into the codebase every day or two), and if you're not extremely careful it can lead to over architecting solutions, or having to throw them away - both of which you'll recognize as being the exact things that agile methods are trying to eradicate.

Still, I sleep better at night knowing that a system I wrote now a year and a half ago is going to make it into the game we're working on with nearly zero modification since I first checked it in.

Jake Simpson

I am in complete agreement with what Simon said (even down to coding style!) - I would add just one thing to what he had to say.

In my approach when I deliver a completed system I want to ensure it used there and then - so if there are any discrepancies between whats there and whats required (which hopefully there won't be if the requirements were gathered correctly), or discrepancies between usage of the system (which generally there usually is - some API approach missing or "But I need it to do X as well, I just assumed you would do that") then I can do it and fix it there and then rather than waiting 6 months till I've well and truly forgotten the code and have to spend 2 days spinning through it to remember what I did and why.

Simon Cooke

Jake - yep, that one's bitten me too. I have a tendency to get quite visibly irate when someone files a bug on a system that was checked in 3 months ago, because they haven't used it yet, even though I was getting continual pressure from them to finish it so they could use it. Grrr.

The comments to this entry are closed.

The Games

  • Energy Hook
    3D grappling-and-swinging-and-running-on-walls-and-doing-tricks ... with a jetpack ... for style!

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