Manager In A Strange Land: Theory of Drag, Part 1

Finally getting started on this, the text version of my talk at the IGDA leadership forum.  Just got my talk reviews back and there's a Love It Or Hate It thing going on.  Some of the Haters were particularly brutal, making the trolls who every now and then appear in the comments on the blog look like gentle friendly neighbors, and making me wonder if it really is "better to be ridiculed than ignored."  But at least they've gotten me motivated to get this stuff written down where I can debate it with text rather than voice.  Much more comfortable with text.

Schizoid is the first project where I've used the velocity-tracking scheduling method from Scrum / XP / Cohn's *Agile Estimating And Planning* - and, on one hand, I've got to say I have never so dramatically underestimated a project.  On the other hand, seeing our progress, from the beginning of the project, as a graph of work-remaining-to-be-done over time, and using that to estimate our velocity, has crystallized something for me.

The graph looks like this. 

This graph looks familiar - it looks a lot like the "bugs remamining" graph of a project that's well into QA.  And if you stare at it until your eyes glaze over, which I have done many times, you see a trendline that looks something like this:

The curve is also familiar.  It looks a lot like that long-tailed power law curve.  (We're not actually on a power law, thank God, otherwise we'd never cross zero, but it's a lot like that.)

And suddenly I realize - if I had used this method to track my many previous projects, I would almost always have seen this curve.  (Tony Hawk 2 for the Dreamcast the one exception, the only project I've scheduled that was a slam dunk, hit the scope we promised, hit the date we promised, hit the budget we promised, 90+ on gamerankings miracle.)

Because on all of these projects, we'd slip, and we'd push our ship date back proportional to the slip.  (We aren't committing that classic rookie mistake of sliding the ship date back one week for a one week slip - the ship date moves back proportionally.)  And yet - we slip again. And again.  How can this happen?  If we've factored in our velocity from those first slips, we should be golden.  Unless...

Velocity ain't constant.

This should have been obvious.  Every project I've worked on seemed like it was going great at first - and then:

"This isn't going great anymore.  We should stop adding features."

"This is going even worse.  We should cut features."

"This is going still worse.  We should transfer people from other teams."

And, finally - "We better crunch."

It's Fred Brooks' werewolf - project seems fine at first, turns into a monster at the end - the one against which there is no silver bullet.  But unlike a werewolf, the project doesn't turn on you overnight - it gets hairier and hairier as you go along.  Like Brooks says - "How does a project end up a year late?  One day at a time."

Once I discovered this I talked to a few others about it, and not just in our industry - this "diminishing returns" curve seems to be everywhere - it's not just because I shouldn't be scheduling.

So, how about your projects?  Is it only after you're well into production that you realize you're in trouble?  Do plateaus and long tails sound familiar?

Next post I'll talk about some of the causes of these "diminishing returns" projects, one of which is drag.

Comments

[Hugh]

Wow. That's VERY interesting. I strongly suspect that if you plotted BloodSpell on a graph you'd get about the same curve. Could it be we might have an accurate way to predict schedules?

Really looking forward to the next in this series.

Also - damn, those power-law curves get everywhere.

[Evan Weeks]

That's amazing, Jamie. I suspect you could plot my current project almost exactly the same way. We're about halfway done and the beast is starting to get hairy, that projected alpha date far too close for comfort.

Definitely looking forward to the next post!

[Pag]

That graph may show why prototyping works well: you're only working during the initial part of the curve, where velocity is high. That's where you get a lot done in a short time, so it's the best time to try things out.

[Jake Simpson]

Just done a blog update on this information - see the web page link -

http://tinyurl.com/2hkpr2

Jamie, you've just proved something I've been saying for a while now and it's nice to have someone independent prove rather than just have me wittering on about it.

[Patrick Hughews]

I see that curve as showing the side effect of the complexity of interaction of components within the project itself. I think it is a 2nd order effect based on the acceleration of interconnects that arise naturally during development. I may be seeing ghosts, too =P

During prototyping and early in development there are few interdependencies and this curve stays flat and work is as fast as it can be.

I see the nasty spike during the first integration pass before entering production, this is where the prototyped parts all start to work together and the initial hit as the number of complex interactions rise rapidly.

Then production goes smoothly, the complexity is not increasing at all and work is as fast as it can be.

At the final third tunes and tweaks arise, causing more and more change and the curve you see is affecting the velocity in a smoother, but accelerating fashion.

In a theory of drag, you could say it looks similar to wind tunnel test curves of drag vs. velocity.

http://www.dpa.unina.it/adag/eng/images/wind_tunnel/017_aircraft_g97_fuselage_drag.png

[TimL]

Jamie, when I heard your talk I had an ah ha moment as well. Despite any skeptics, I think you are onto something real here that at the very least teams should debate on to use the concept as a sort of tool to test out difficult times they might be having. At best it becomes fully adopted. I know I'm going to be having this conversation with my team when the time is right. Thanks again for the revelation.