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.