I've been thinking about the kind of people who disagree with the 'theory of drag' - the idea that as a project progresses your velocity slows down, the 'pushing a snowball up a hill' metaphor - and wondering what their beef is when it's, well, so obviously true.
I've rarely met these people in person, though I do have anonymous feedback from talks I've given - but I have a couple of theories about who these people might be.
One is the 'go team!' producer. I heard a producer say the other day that the primary number-one job of a producer is to make the team feel like they can ship. Keep the morale up. "We can do this! Go team!"
The 'theory of drag'...which, summed up, says 'Your project is more screwed than you think it is' isn't what that kind of producer wants to hear, or spread to the rest of the team.
I don't know if that sort of producer is as wrong as they sound. An optimistic, happy team will be more productive than a "we're doomed!" team. Like JFK saying we would put a man on the moon within the decade: you can galvanize a team that way.
But the ideal is to embrace "the Stockdale paradox" from Good to Great: always have faith that you're going to make it while simultaneously being able to confront the brutal facts of your current situation. And someone embracing the stockdale paradox would want to always keep drag in mind.
Another kind of detractor is the scrum guy. I was talking to a scrum expert, and I told them that in my experience velocity always decreases as a project goes along, and they said, "Really? In my experience, velocity always increases, as the team gets more used to their tools and technology."
Frankly, I think it isn't becuase they're mastering their tech--seriously, in my experience the gains from mastering tech are always buried by feature creep and the drag from project bloat--but because scrum has some dishonesty built into the scrum process. When doing scrum, you have the project backlog for the entire release, which is estimated in arbitrary time units...let's call them quatloos. And each sprint, when a team commits to the work they'll do for the sprint, they more rigorously estimate the tasks they're about to undertake, in man-hours or man-days. The thing is, scrum guys measure their velocity in terms of these man-hours or days that they re-estimate every month, so what I think is happening is this.
Sprint 1: team takes on a chunk of work. It takes a little longer than expected. Their velocity comes out at, say, .9.
Sprint 2: team consciously takes on a smaller chunk of work. Because of drag, it takes a little longer than expected, but because it's a smaller chunk, their velocity appears to go up to say .95.
Sprint 3: team consicously takes on a still smaller chunk of work. Etcetera.
I think you'd find if you looked at the velocity in quatloos, you'd find it was continually decreasing, as they both got fewer quatloos done due to drag and added more quatloos to the project due to feature creep. They're committing to fewer quatloos every sprint.
Measuring a project in quatloos obviously sucks, because it's so damn hard to predict how long a feature is going to take a year down the road, and that's part of the reason drag increases near the end of a project. But I think if you want to be honest about your velocity it's the only option. Also, if you're a contractor who needs to promise a certain feature set by a certain date, it's all that really matters. You can't go to your client or publisher and say, "Well, we've gotten to the last sprint and discovered that we can't commit to all the backlog we originally promised. Sorry, but we're doing scrum, so that's how it goes."
Instead, if you measure every project in quatloos, although those first couple of projects may shock you with the massive amounts of drag you experience, after a while you'll start to expect it and be able to bid accurately on contracts - and cheesy rules of thumb like "try to be 90% done 50% of the way through the project"--in other words, get 90% of those quatloos done at the halfway point--may save your ass.