[kabdib]

The classic success cases for Scrum were projects that had (a) been done before, and (b) been done by the same team.

So they had lots of experience.

If you ask an assembly-line worker "How long is it going to take you to install this transmission?" they'll be able to tell you within a few seconds. But that's not engineering.

If you ask someone who's written essentially the same app five or six times before "How long will it take you to finish feature X?" they'll be able to tell you with pretty high confidence.

If you ask someone, "How long is it going to take you to finish designing and implementing that gozzlewog?" they won't have the foggiest idea. Ask them again, when they've re-implemented it a few times, and they'll have an idea then. Until then you can decompose the problem and do analysis on the pieces and make assumptions, but you still won't know how long it'll take until it's done because the industry has been doing this for like 70 years and the one thing we know is that scheduling unknowns and unknown unknowns is still very, very hard.

Scrum works if you've done it before. Apply it to green fields or systems with known wicked behavior, and you're likely to fail in quite a few ways, including pissing off your developers and boiling off the good ones for better work environments.

[madcaptenor]

An actual example I've seen: you can ask a field technician "how long will it take to install this piece of equipment in the field?" and get a pretty good answer. You can't ask a data scientist "how long will it take to build a statistical model to predict how long jobs out in the field will take?" and get anything at all useful.

And you certainly can't ask "how long will it take to build a statistical model to predict how long it'll take a data scientist to build a statistical model?"...

[couchand]

If you ask someone, "How long is it going to take you to finish designing and implementing that gozzlewog?" they won't have the foggiest idea.

That's technically true but not useful. There are much better questions to ask, namely:

  - Will gozzlewog or foofaraw take longer to implement?
  - Is the difference minor or is it an order of magnitude?
  - Will shipping gozzlewog or foofaraw make a bigger impact on the business?
  - Is that difference small or large?

All of theses are easier to estimate and are more useful, too.

[kabdib]

Can't tell if serious or not.

If a gozzlewog is something you haven't done before (and maybe nobody has done it) then you have much less data to go on. Coming up with an estimate for it can be really, really hard. Want to decompose it and estimate from there? Hey, you just fell into the trap.

I wish I had a dollar for every time I've heard someone say "That turned out to be harder than I thought." And this is nearly always the case when you're doing something new. So you hem and haw and pad and you're late anyway . . .

But my stand is that you're actually not late, you're actually on time and it's just that the estimate you made (or that someone made for you) sucked. You don't even suck at estimating because you can't reliably estimate something you haven't done before.

Oh sure, small things. But not big things. Probably not even medium-size things.

Imagine you're in a scrum planning session and someone says, "Hey, we tagged you for implementing Gozzlewogs" and you have absolutely no idea what a gozzlewog is, or maybe you read about them a while back so you're the person that people come to when they hear "gozzlewog." But you're on the hook for it, and they want an estimate and the answer of "I don't know" apparently isn't on the table.

So do you:

- Dig in your heels and say "I don't know" anyway?

- Lie and say "Two weeks" because half of the dev team is in your shoes and doing the same thing, and you'll all slip together? Besides, next sprint it'll be the same bullshit, except with frumwidgets in addition to the deep, complicated and tricky stuff you discovered while investigating gozzlewogs.

Now, clearly this is broken, and it's not even the fault of Agile, but rather the middle management that thinks developers are fungible and cog-shaped, and that everything can be decomposed and predicted, and that you can have a schedule with a granularity of days when your known unknowns are at the scale of multiple weeks.

[couchand]

Here's the thing: by the time you really know how long a feature will take to develop, you've done it. Until then you need to operate on an estimate. EDIT: I see you edited your comment to include the same sentiment while I was replying. Cheers!

People are bad at estimating, particularly if they're doing it alone, don't have much information or are trying to estimate absolutely. But we're pretty good at estimating relatively, doing it in groups (witness bean counting contests) and even with just a little information we can make improved estimates.

So the ideal task planning in my mind goes like this: the team gathers around the backlog to see what we think the next priorities are. Briefly we chat about each one, enough that everyone has a basic sense of what it is and no one is blindsided. We intentionally don't want to talk about it enough to implement it, just enough to get a sense for it.

The team then collectively estimates the size of each item with a hidden bid system: each person picks a number on an arbitrary scale (let's call it points) that only has meaning relative to the point values of the other things on the list. Once we have a handful, it becomes pretty easy to say "foo is harder than bar, but not as bad as qux".

[kabdib]

Cheers, indeed. (Sorry about the edit . . . it's the way I think). Happy we're in agreement.

Part of my problem with Agile is that my bad experiences have made me cynical and somewhat allergic to it. I react badly to being micro-managed and gamed by managers who are fundamentally out of touch with the reality of writing software, and who are interested in making the deck hands row ever faster so they can look good.