When Agile jumped the shark

http://deathrayresearch.tumblr.com/post/27257008711/when-agile-jumped-the-shark

by ljw1001 • 14 years ago

20 25 14 years ago

deathrayresearch.tumblr.com

It used to be that you had Earned-Value Management and the concomitant EV Charts. One could take the first derivative of the current point on the chart (or perhaps do something fancier involving moving weighted averages) and use that to predict[1] how the EV chart would play out in future.

But EV charts and first derivatives are old fashioned and hokey. Practically waterfall!

Instead we use the latest in agile management: burndown charts and velocity. Totally different.

[1]: Though see every software project ever for an example of why linear extrapolation is a hilariously foolish way to settle on a firm estimate.

DanielBMarkham8• 14 years ago

This was a bit meandering, but I feel his pain.

I was very skeptical at first, but I've become a big fan of story points: they decouple estimation from scheduling, and that's a good thing.

Note that they are not "... a new, fuzzy unit of measure..." likewise they are also not a "...metrics sleight-of-hand..."

This a very simple, yet powerful exercise. Relatively size the things you have to do. Now, without caring about what the points are, select what you can do in the next time-frame. Measure your ability to deliver against this.

Over time, your relative estimates get better and your ability to commit gets better. The kicker is that none of this has a damn thing to do with scheduling. Once you can tell reliably tell me you're going to deliver 10% of the remaining total work in the next two weeks, I know for a fact you have 18 more weeks left in the project. Then I can then release plan and work dependencies based on real-world data and without breathing down a developer's neck. Meeting schedules doesn't have to be (and shouldn't be) the higher-stress thing many of us make it out to be.

The author seems to not be able to get scheduling out of his head. If you're constantly wondering how many days a story point is, don't use story points. You don't understand them.

Note that for such a simple idea, there are several gotchas here. Most teams screw up story points and velocity. Anybody have the PM that divides the points by the sprints remaining and then announces what the velocity will be? Or how about the ScrumMaster that empirically determines current velocity and then tells the team how many stories they can do for the upcoming sprint? Ouch. Lots of bad practices out there. That doesn't make story points bad, though. Just makes most people suck at them. (Shameless plug: I have a book on being a ScrumMaster and an upcoming one on backlogs. http://tiny-giant-books.com/scrummaster.htm )

ljw10014• 14 years ago

If they're not fuzzy, how big is a point?

DanielBMarkham8• 14 years ago

It's not fuzzy. It's unit-less. The number has no size or meaning outside the list of other sizes representing the work for that particular team for that particular sprint. It doesn't transport between teams, it doesn't mean the same thing from sprint to sprint, and it doesn't represent any qualities of the underlying system. You're asking for the definition of something that's just a relative number. It's like asking how long a piece of string is.

That sounds whacked, so let me try again.

What I'm doing when I take a list of future system behaviors and ask a team to relatively them is creating the parameters to a model that doesn't exist yet. The process of creating, revising, and implementing the model is what the team does each sprint. That's why initial estimates are so whacked (and they should be). Yes, for your particular team on your particular project maybe you get to the end and say "Hey, on average a story point amounted to 1.5 days" But I have no earthly idea why anybody would do that or care about that translation. It would a _very bad thing to do_. You only know the "answer" once you're done. And the answer is empirically determined by application of the model; it's not a guess.

Remember the old quadratic equation? ax^2+bx+c=0? Story points are like knowing "b". So how big is "b"? See? Makes no sense. It's just part of a parameter used to do other things. "Size" has no meaning here.

jacques_chester6• 14 years ago

Decoupling estimation from scheduling is not something that was invented after the Agile Manifesto.

The rule for serious estimators has always been to estimate size first and schedule second. I'm talking wisdom that's been around for decades. Pretty sure Boehm was talking about this as far back as the first COCOMO. It's literally older than I am.

I've only ever seen agile use time as a unit of size (the "ideal day") and it leads to the sort of trouble you're thinking of: conflation of size estimate with schedule estimate.

Non-time estimations might have been expressed in SLOCs, representative ojects, function points and so on. Inputs to estimation could include expert opinion (PERT, Wideband Delphi), historical records and judgement (COCOMO) or early process artefacts such as the number of paragraphs in a requirements document (PROBE).

I'm only 31. It shouldn't be the case that I am the "old fart" here. Sometimes I feel like I'm the only one talking about work, damn good work, that was done before agile came along and apparently hit the memory-flush button on an entire industry.

DanielBMarkham8• 14 years ago

Agile is best practices around iterative and incremental development. That's it. It's a marketing term. Of course most of this stuff has been around forever. Most folks who "get" Agile say something like "This rocks! It's like we used to do things when we had a lot of fun and kicked out a shitload of code."

From observing teams the interesting thing is how many people used these techniques back in the day, stopped using them over time, and then don't want to go back because it's something "new". People are strange.

spacemanaki• 14 years ago

> The kicker is that none of this has a damn thing to do with scheduling. Once you can tell reliably tell me you're going to deliver 10% of the remaining total work in the next two weeks, I know for a fact you have 18 more weeks left in the project.

Wait am I missing something or did you just say that this has nothing to do with scheduling but then extrapolate some estimate in order some up with a schedule? (not trolling, legitimately confused)

DanielBMarkham8• 14 years ago

Yes. What you end up doing is getting good at determining what percentage of remaining work you can accomplish in each sprint. This information can be applied offline to schedule. You get a schedule without ever having any conversation about duration or time. The "magic" works because by picking what you can do in a sprint, you are associating a certain percentage of work with a time unit. So you it's not like there is no time discussion. It's more accurate to say that you don't keep multiple sets of books.

Like a cool programming concept, it's one of those things that once you see, you're like wow! But granted it can be a head-scratcher beforehand. Like I said, I came at this as a skeptic. Once you see it work in multiple teams, however, you don't want to go back to the old way. It just doesn't make any sense to do it like that.

ars_nihili• 14 years ago

  > Or how about the ScrumMaster that empirically determines
  > current velocity and then tells the team how many stories
  > they can do for the upcoming sprint?

Honest question: how should a team manage what will be done in the next sprint without basing on its velocity?

edit: formatting

DanielBMarkham8• 14 years ago

This also applies to the T-Hawk's question.

Velocity is the empirically-measured percentage of backlog complexity that the team can reliably deliver. It is determined (and varies over time) as the problem gets solved.

It's a measurement, not a control factor. The team has control, not some number. Look at it this way: each sprint when you look at the work, you keep getting better and better at executing: your unit tests are dialed in, the CI server is rocking, you figured out that cool thing where you cut the amount of code in half, and so on. So when you look at what you can honestly do in the next sprint, that's an important piece of business feedback that other people need. You're "recalibrating" the release plan, which you should always do because stuff changes. In Agile, when you pick what you can do at the beginning, the whole schedule slides around. Business guys know at the front of the sprint that things are out of whack. That's great. It gives them the entire sprint to figure out what to do. In other systems they don't know until the end, which sucks for everybody.

Doing it backwards provides absolutely no new information to the business. You're saying the problem hasn't changed, the team hasn't gotten any better or worse, and there are no new risks. Instead of adding your expertise to people who are looking at the big picture, all you're doing is playing some kind of game.

Combine this with other bad stuff like never re-estimating or re-stating the backlog (or having a 3,000-item backlog) and it's like taking a sports car and putting a lawn-mower engine in it. Yes, you can call it Agile, but you're really doing it in a very painful and inefficient way. That hurts. Don't do that.

btilly• 14 years ago

Once you can tell reliably tell me you're going to deliver 10% of the remaining total work in the next two weeks, I know for a fact you have 18 more weeks left in the project.

Really? I would automatically estimate 38 more weeks.

The difference being that once someone is confident of their figures for time periods that long, they are generally wrong by a factor of 2.

In essence this is a disagreement about what "reliably" means. But in general time estimates tend to be "the smallest number that nobody can prove is wrong" rather than "how long this is likely to take". And you can tell that because there is a nice little plan, and a breakdown of how long each step could take, with no big fudge factor for "Things we don't know about yet, like the requirement that we'll get told about in 2 weeks."

Cynical? No, realist( * ). ;-)

* Cynics always claim to be realists.

T-hawk• 14 years ago

Story points vs time estimates is not an either-or question. You can use both. My team at my job does. We do time estimating for each two-week sprint (Scrum) so we know what will fit, and have fuzzier point estimates in the backlog for longer-term planning by the product owners. Both levels of abstraction are appropriate in the right context.

To DanielBMarkham in a sibling comment:

> Or how about the ScrumMaster that empirically determines current velocity and then tells the team how many stories they can do for the upcoming sprint?

That's what we have, but is that bad? Isn't that how the points should be used to gauge predicted velocity? Of course it shouldn't be treated as a concrete inviolate set-in-stone prediction, but that methodology comes in pretty accurate for estimating.

ljw10014• 14 years ago

Not totally different, but simpler, which counts. Earned value presupposes things like someone put a value on individual deliverables and that there's a budget that matters. Neither happens much in commercial software in my experience.

Since most software cost is headcount * time * cost-per-person, tracking time is a pretty good proxy for that.

Of course no metric matters if you produce bad code and call it progress.

bradly• 14 years ago

My big problem with estimating in story points is that it ignores the reality that how long something takes is directly tied to who is doing the work. A junior eng, a senior eng, someone who just started, someone who isn't familiar with that piece of the system, the person who wrote and has always maintained that piece of the system. These people will all do a given task in a different amount of time. Possibly an order of magnitude differently when comparing a junior eng not familiar with the code to the codes author. This is okay. Embrace it. Plan for it.

amurmann• 14 years ago

I would argue that this is actually an advantage of story points. You don't know who will be working on it at estimation time. But a 2-pointer should take any developer about twice as long as it would take the same developer to do a 1-pointer. If you have many super fast, very senior developers you get more points done and have a higher velocity. That's where the speed will be reflected and you can see how much your team can get doen in one iteration. This allows you to plan your iteration without having to care who works on any given story.

ljw10014• 14 years ago

On a sufficiently large project (more than a few people) the differences in productivity average out, as do to some extent estimation errors. I never expect any individual estimate to be correct; it's more important to get an accurate estimate of how far off your estimates are in aggregate.

When Agile jumped the shark

Related Stories