
When Agile jumped the shark - ljw1001
http://deathrayresearch.tumblr.com/post/27257008711/when-agile-jumped-the-shark
======
DanielBMarkham
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> )

~~~
jacques_chester
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.

~~~
DanielBMarkham
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.

~~~
jacques_chester
> Agile is best practices around iterative and incremental development. That's
> it.

I wish I could broadcast this on TV.

~~~
DanielBMarkham
You should attend one of my classes. I ask what Agile is and then tell
everybody it has no meaning at all. It's just a big blanket term we use to re-
wrap a lot of that older stuff (and some new stuff too).

In my opinion the biggest problem Agile has comes from the people who like it.
Skeptics are fine. I can show you this stuff works. But people who did "Agile"
one time and become cheerleaders and set in their ways can be insufferable.

~~~
jacques_chester
I'm mostly peeved by the goldfish memory this industry exhibits.

Partly a function of the pyramidal demographics, I suppose.

The ACM and IEEE doing the whole Smaug routine with the treasures of decades
of research isn't helping either.

------
T-hawk
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.

------
jacques_chester
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.

------
bradly
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
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.

------
ljw1001
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.

