'Theory of Drag' detractors

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.

And if you haven't seen my posts on the theory, here they are plus.

Comments

[Bryan McNett]

You're right, and this law of diminishing returns applies broadly to human endeavor (e.g. exploitation of natural resources:)

link

[Hugh Hancock]

This may be a dumb/previously answered question, but - quatloo? Not a term I'd heard before.

[Josh Szepietowski]

I am sensing a little disdain for Scrum by your choice of 'quatloos'.. :) Perhaps it is just a little confusion.

As I understand it (any 'Scrum Masters' feel free to correct) the 'by the book' implementation of Scrum:

• Using an imaginary unit of measurement (usually called 'Story Points', but let's roll with quatloos) exists to keep honest about schedule in light of the realities of things like Drag.
• Quatloos should be the unit of measurement from top to bottom and they are a metric for comparing work. (if A is 2 quatloos then B seems like it would be about twice as hard as A, so lets say it's 4)
• The velocity of a team in a sprint is supposed to be measured in quatloos. This is how you arrive at the equation for how much time 1 quatloo equals. Since the velocity may change (say, from drag), the time-value of a quatloo may change.
• "They're committing to fewer quatloos every sprint".
  • This should be reflected by decreasing velocity. What is velocity a measurement of? Work/time. What is the unit of work we are using? Quatloos. If taking on less quatloos results in higher velocity than the team is being dishonest to themselves in their velocity calculation.
• "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".
  • Absolutely true and far more-so for teams recently adopting Scrum since they have less idea of their velocity. However I say it sucks for different reasons: it isn't because quatloos are imaginary units, it is because a quatloo does not have a constant real time equivalent.

    However if you estimate a project out in 'days'.. Aren't you just calling a quatloo a day? Afterall a day isn't a unit of work. A day is a unit of time. Estimating in days leads to amazing situations like: "This week we got 3 days of tasks done". If your days/week velocity changes (due to drag) doesn't this mean you need to either adjust remaining task times to the new reality?

    Personally I think this is one of the strongest reasons Scrum (and other Agile methods) have not spread faster. They reveal the truth: things are unpredictable. A Scrum team can do what a non-Scrum team does and promise X work in Y time. Is there anything about measuring tasks in days rather than quatloos that makes the process of estimating long term tasks more accurate? Less prone to fall pray to drag?

    The only difference is a Scrum team is going to have metrics screaming the reality of the situation the entire time. The reality might not be pretty.
    

[Wm]

Ah, I see your disconnect:

In Scrum, a team's Velocity is how many "quatloos" they've committed-to and completed, not the time the work actually took. It's the original "ballpark" level-of-effort estimate, not the after-the-fact time spent, that determines Velocity.

As the team gains experience working together, it's natural to see their Velocity increase by, oh, 10% or so. (It typically stabilizes around Sprint 3, and remains there unless the team make-up changes.)

Quatloo estimates do change a little as the team commits to them (I see them go down more often than up), but again, its those estimate values that, once completed, become a team's Velocity.

[greggman]

I'm not even sure we that I'm talking about the same thing because my experience seems mostly totally backward to yours.

It always feels (I guess I can't prove it) that speed increases in the majority of projects I've been on. The team gets used to the tools. The designers understand what works and aren't experimenting anymore. The artists know what they can and can't make. Everyone has gotten used to the system. All that stuff that was taking forever because no hard decisions had been made are now over and people are just churning out massive amounts of content and finishing up features.

I don't really see how it could be otherwise but then maybe it's a difference of perception. My perception is each month, the number of things getting done accelerates. I'm pretty sure that is objectively true for pretty much every project I've been on.

On the other hand, maybe it's a different approach. You mentioned feature creep. My experience is feature creep increases up to the first 1/2 of the project and then quickly decreases on the last 1/2 including cutting planned features there is no time for.

[Simon Cooke]

I'm a big fan of "be 90% done, 50% of the way through the project".

However, there's another trick.

Tell the team: If everyone is done with their work before the deadline, it's all wrapped up and put to bed, you get the remaining time to do with what you will.

Vacation? Research? Pet projects? Sure!

The important word in that sentence is "everyone" - it gets people in the mindset of helping the stragglers so it doesn't eat into their vacation time. It also makes people focus their work, and not spend time doing random silly stuff.

(And it also gets the project managers scheduling things accurately so that they don't waste money on having the office idle - mind you, the schedules need to be worker-driven in this case, or it's unfair).