Manager In A Strange Land: Theory of Drag 2.5

Before I go on to Part 3 and what we can do about drag let me deal with some of the discovered work unearthed by the comments on Part 2.

* Graph Quality

Mark Nau calls me out and says he doesn't see the curves.  If we still worked in the same office I probably would ask him to help me do an actual rigorous statistical analysis of the data.  The curves are there but they look shallow and I admit I was pretty disappointed after generating the graphs that they weren't more obvious.

As for not seeing much of a bump when we brought the new programmer on, I can explain that.  He's only part-time - I'd estimate at him increasing our manpower by 25% or so.  Factor in Fristrom's Law and it's less.  He needed a ramp-up period.  And his first task was huge but greatly underestimated.  It could have shown on the graph as a simultaneous increase in scope and work, but instead it shows on the graph as an increase in neither.

But that goes to prove Mark's point - the graph isn't accurate.  I'm not able to truly tease apart work and scope, and probably won't even bother on future projects.  (Though it was nice to see that we actually have been working all these months, something that isn't obvious from the first graph.)

Still, it's not two straight lines.  Keep in mind that first graph:

This graph is simply the delta between the two lines in the other graph - though they don't plot out to the same point in time;  I made the graphs at different times.  If the lines in the other graph were straight, this graph's lines would be straight as well, but this is not a straight line.

* Other curves?

Jake Simpson and Simon Cooke say they see different shaped curves on their projects - they both see sine waves or something approximating sine waves.  It is possible on this project we're just looking at a portion of a big sine wave with a really large period.  Which would be a good thing, because that means at some point we'll take off like a rocket and ship!  I wouldn't be surprised, actually, if we do get a burst in the end, as we put our foot down about feature creep and the remaining bugs are all highly detailed spot fixes.  If only there was some way to predict when that change would come.

Cooke sees the opposite from us, in a way:  he sees little visual progress in the beginning, during ramp-up, later followed by a lot of visual progress.  (Much like our programmer with his big, underestimated task.)  He may be more waterfallish than we are - we tend to get something up-and-running *now* and refactor later.  For us, the "up and running now" shows up as a lot of progress, and then the refactoring shows up as drag.  (Maybe this agile stuff isn't all it's cracked up to be.)

* Feature Creep vs. Discovered Work?

How much scope increase was stuff we wanted vs. stuff we needed?

FWIW.  Red & most of green are needed.  Blue, yellow, and pink are wanted.  Call it 60-40.

Though I hesitate to call that 40% literal 'feature creep' - most of our unnecessary fixes were not "add X" but "X would be better if you do Y".  The feature was already there and we were tweaking it.

More interesting would be to see how this changes over time, but I didn't know until late in the project that you could set up Bugzilla to generate snapshot data that you can later graph.  It would be fraught with inaccuracy anyway - at the beginning of the project, p3 meant must-fix and later came to mean nice-to-fix.

I'm guessing Busse's point:  if you tighten the reins on feature creep, you can mitigate the effects of drag.

I'll try to get back on track next week, unless there are more interesting comments.

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.