[throwaway1979]

"Productivity ground to a halt for six months"

My experience feels the same way. I am beginning to think Agile works for UI dev and small teams of inexperienced folks building relatively simple projects. If you have a large team building something complex, the constant meetings and tool updates destroy productivity. What's worse ... they destroy developer morale if you are actually a good dev IMHO.

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

[UK-AL]

It's roughly 2-4 hours worth of meetings in 2 weeks. That "destroys" productivity?

[wilsynet]

If you are doing Scrum, the development team should be doing something like over 2 weeks:

Daily standup: 15 mins x 10 days = 150 minutes = 2.5 hours Backlog grooming: 0.5 - 1 hour Sprint planning: 0.5 - 1 hour Retrospective: 1 hour Demo: 1 hour

So about 5.5 - 6.5 hours of meetings over 2 weeks. If you're really militant, you can probably take it down to 4 hours, but I don't think you can get much lower than that without dispensing with formal Scrum.

It doesn't seem unreasonable to me to have 6.5 hours of meetings over 2 weeks.

[UK-AL]

Your backlog grooming is a bit to long. You should only be grooming 10-20 tasks.

[zimpenfish]

I've been in standups that lasted an hour a day. That'll destroy your morale pretty damned quick.

[wilsynet]

They are doing it wrong. 8 people should not take an hour to say: What did I do yesterday, what am I doing today, is there anything blocking me?

There should not be a discussion of every point. The only discussion should be "oh let's talk about that impediment after the meeting with a smaller group of people" or "let me follow up with you after lunch".

The standup is 10-15 minutes. If it is longer, it needs to be stopped. Period. Non-negotiable.

[jackmaney]

> There should not be a discussion of every point. The only discussion should be "oh let's talk about that impediment after the meeting with a smaller group of people" or "let me follow up with you after lunch".

Guess what? Those things are still meetings. They still take up actual time that could be spent on getting shit done.

[lostcolony]

They don't, however, involve everyone. The standup does. That's key. If person A needs to talk to person B about an issue, and it's done in standup, it wastes person C, D, etc's, time, even though they don't need to be involved. Doing it with just the required people is, obviously, required anyway, and the problem a lot of people doing agile have is they end up wasting everyone's time by bringing it up during standup.

[jackmaney]

A 45 minute meeting that spawns off of a 15 minute meeting is still a total of 60 minutes of meeting time. And yes, while that 45 minutes involved fewer total people, that doesn't mean that others won't have spin-off meetings of their own.

[davidgerard]

So, have you ever said "Anyone going over sixty seconds will be shot" and there's that one guy - or two, or three - who nevertheless always take five minutes? Yeah, turns out you probably can't actually shoot them.

[wilsynet]

No, but you can cut them off and say "I'm sorry but we need to move on, you have 5 more seconds to finish what you're saying".

[davidgerard]

You can indeed do that. Sometimes they even stop! Not very often, though. Again, the inconvenient lack of actual bullets.

[zimpenfish]

There were frequently 10-15 people in the standups. And sure, you can say "if it's longer, it needs to be stopped" but management doesn't work like that.

[jackmaney]

Let's not forget the daily leadership meetings and weekly all-hands standup. Those are a real hoot...

[jjoonathan]

No, incentivizing small tasks that look good in standups over larger, less-sexy tasks kills productivity.

[jackmaney]

Only 2--4 hours? I wish.