Hacker News Reader

Comment by deckard1 | Hacker News Reader

> break everything up into smaller chunks. It gives you clearly defined guardrails

This is only true if management respects the estimates. In my experience, they do not understand why Fibonacci or t-shirt sizing, etc. are used. They mentally convert the points to some "X days" and then beat you in the head with it. They want to micromanage and they do not understand they are building software. You can't break certain tasks down further and you can't parallelize many tasks. You can bring up Fred Brooks but it's a hopeless cause. They will never get it. Then as you inch towards their arbitrary deadline (that they tell no one, by the way, because it's better the developers don't know about deadlines until the last fucking minute because "agile" and not "waterfall") they suddenly act shocked that 9 women really can't make a baby in one month.

But I digress.

View on HN

    They mentally convert the points to some "X days" and then beat you in the
    head with it.

That's actually why I really dislike Fibonacci estimation. If we just estimated days or hours, then I could say, "Okay, this is going to take me until Wednesday," my manager would reply with, "Wednesday? It's going to take that long?" and then we could have a discussion about why it's going to take so long. Or, worst case, manager says, "quanticle, I really need this to be done by Tuesday," and I know I'm going to be staying late until it's done.

But with Fibonacci numbers, it's like, I estimate a 3, manager nods and agrees that this task is a 3, and then it turns out that when I said 3, I meant that it'd take until Wednesday, but manager thought that a 3 point task would be done by Tuesday, and now manager is mad at me, and I don't know why.

The old way sucked, but at least it sucked in an up-front and transparent way.

When you vote in Fibonacci and it's really simple, do you vote a 1, or 1?

I prefer 1 or 0, do or do not. The rest of the sequence is meaningless. If you are truly in a position where two different features will bring the company £5mil of revenue and one is a 3 and one is a 13, just do both, no need to prioritise the 3.

For me the most absurd conversation around Fibonacci estimation is the burndown (etc) charts and group estimates.. you can't add non-linear values and expect the sum to mean anything!

I've had managers fight over how the upcoming sprint is doable because it has around as many total points as the last, ignoring that they've defined the individual five-pointers as being significantly more effort than five individual one-pointers. And they either fail to grasp the issue or deflect when it's pointed out.

Agile is a cudgel.

That brings to mind the other issue I have with fibonacci estimation: it makes improvement impossible.

In any high-performance organization, there is periodic self-reflection and self-improvement. Professional sports teams will, for example, sit down and "watch the tape", reviewing video of their most recent game(s) to see what they've been doing well and what they've been doing poorly, drilling down into specific areas where they need further practice.

Agile pays lip-service to this practice with its end-of-sprint retrospectives, but I've never seen an agile team do anything approaching a ticket-by-ticket breakdown, going over why the estimate was wrong, and what could be done to improve estimation in the future. One of the reasons that teams don't do this is because Fibonacci estimation makes it impossible to do this sort of thing. If I estimate that a task was a "3", and it took me two days to finish, did I estimate correctly? How could I have estimated better? These questions don't even make sense without a common baseline for what these numbers mean.

That's what I find most frustrating about Agile, as it is practiced. It's not the fact that the estimates are wrong. It's the fact that the estimates are so meaningless that they're not-even-wrong, in a way that makes it impossible to find and adjust for biases.

> and I know I'm going to be staying late until it's done.

I cant tell you how many times I spent long days, 16 hours at a time, sometimes over the weekend etc. Only to have the manager stroll in monday talking about how great their weekend was, and barely acknowledge the item was completed. And then I find out the customer that "needed this so bad" didn't touch it for the next month. Or were never told it was deployed etc.

So many deadlines are fake that it's hard to trust any deadline.

Fake or not, at least you were told what the deadline was. The agile approach to this dysfunction is for you to be pulled aside at some point and told, "You're not delivering enough points," with the manager remaining extremely vague about how many points is "enough".

I think you illustrated the point of the deadline well. How else were they going to get you to work 16 hours days? No way to make someone eat the cost of estimation error by pretending there is no error and making job performance and team esteem dependent on "not failing the sprint".

> manager says, "quanticle, I really need this to be done by Tuesday," and I know I'm going to be staying late until it's done.

At some point you have to grow a pair and create the workplace you want. (Or, y'know, unionize). Tell them to fuck off.

> But with Fibonacci numbers, it's like, I estimate a 3, manager nods and agrees that this task is a 3, and then it turns out that when I said 3, I meant that it'd take until Wednesday, but manager thought that a 3 point task would be done by Tuesday, and now manager is mad at me

They're explicitly not allowed to do that. If they're claiming to follow Scrum then that's a promise not to do that. At some point all I can suggest is "don't work for a liar". Of course that may be easier said than done.

> The old way sucked, but at least it sucked in an up-front and transparent way.

I agree that pretending to follow good practices while following bad practices can be worse than honestly folowing bad practices. But that doesn't mean that good practices are worse than bad practices!

    At some point all I can suggest is "don't work for a liar". Of course that
    may be easier said than done.

The point of my anecdote was to illustrate how Agile makes it easier to lie, and makes it difficult for honest people to call out liars. If a manager tells me that the deadline is Wednesday, and the deadline passes without anything bad happening, then he or she looks bad. If a manger estimates a "3", and I estimate a "3", and then it turns out that our definitions of what a "3" is differ, then I look bad, regardless of whether the work was, in reality a "3", a "5", or a "3.1415926".

    But that doesn't mean that good practices are worse than bad practices!

The worst practice of all is a bad practice that masquerades as a good practice. I'd much rather that people be honest and up-front about the deadline (even if it is BS) than try to hide behind some overly complicated poker-game kabuki.

> The point of my anecdote was to illustrate how Agile makes it easier to lie, and makes it difficult for honest people to call out liars. If a manager tells me that the deadline is Wednesday, and the deadline passes without anything bad happening, then he or she looks bad. If a manger estimates a "3", and I estimate a "3", and then it turns out that our definitions of what a "3" is differ, then I look bad.

If your manager says they're following agile/scrum and says you took too long on that "3", they're lying and you should call them out; you don't look bad, they do.

> I'd much rather that people be honest and up-front about the deadline (even if it is BS) than try to hide behind some overly complicated poker-game kabuki.

If you've got a real deadline then be honest about it. But most everyday tasks don't need a deadline; agile isn't about pretending the deadline isn't a deadline, it's about actually not having a deadline.

    But most everyday tasks don't need a deadline

I think that's the crux of our disagreement. I think most everyday tasks do indeed have a deadline. Even if that task specifically doesn't have a deadline, it's often in service of a broader task which does. The premise that all agile methodologies are built on is that customers are going to be more willing to drop features rather than add days to the schedule. I think experimental evidence has proven that premise false.

And frankly, it was kind of a ridiculous premise to begin with. Can you imagine if other professions adopted "agile" methodologies? Can you imagine your auto mechanic telling you, "Okay, well, putting the dashboard back on is going to take me until tomorrow, actually, but, if I only attach half the bolts and leave the speedometer disconnected, I can get it to you by the end of the day. Would that be all right?" Or a home-builder saying, "Okay, well, the drain pipes are proving trickier than anticipated to install, but I can give you the bathroom without the drain pipes, and install those in the "version 2.0" release. Would that be okay?"

> Can you imagine if other professions adopted "agile" methodologies? Can you imagine your auto mechanic telling you, "Okay, well, putting the dashboard back on is going to take me until tomorrow, actually, but, if I only attach half the bolts and leave the speedometer disconnected, I can get it to you by the end of the day. Would that be all right?" Or a home-builder saying, "Okay, well, the drain pipes are proving trickier than anticipated to install, but I can give you the bathroom without the drain pipes, and install those in the "version 2.0" release. Would that be okay?"

You're talking about stuff that's a regression from the previous state of things, which is rather different. Where I live it's totally normal for a dentist to say "ok, I only had time to fill two teeth today, come back next week for the others". Or a tutor to say "ok, we'll stop there for today and finish the chapter next week". Or a cleaner to say "well I've got time to do the balcony or the fridge but not both, let me know which you want today and I'll do the other next week".

Also, when we say we have an appetite/capacity for X points in the (Y-week) sprint, that would actually make sense!

Drives me mad calling the points 'complexity', explicitly not time, and then talking about how much complexity fits in the allotted time period...

At the end, those complexity number end up representing some time estimates anyway.

Cause you will get the velocity graph, showing how much points have been completed this sprint and how it compares to previous sprints. The graph is expected to stay somewhat level or increase as the team efficiency increases. It will decrease when members are away on holiday.

If your team capacity stays equal and last sprint your team completed 20 story points, it’s kinda expected the next sprint another ~20 story points are completed. So in that case 20 story points will represent about 2 weeks of work for the full team.

I also think for many people complexity translates into time needed to finish work. A more complex task will naturally take more time to complete than a simple task.

So from my point of view, it’s fair (if after a couple of sprints) a product owner might get an idea that 1 point is equal to -say- half a day of work.

PS: I am not a product owner and not a big fan of ”Agile”. I think daily stand-ups might be overkill in many situations (in my current remote team it’s more like a weekly stand-up) and I generally hate retrospectives. I just want to get shit done (which is luckily the practice we have in my current team). We do have a task board, but we don’t do the whole assigning points stuff. And I am mostly free to pick-up any task I feel like working on. This is much more agile to me than “Agile”.

That’s generally true for that specific team in that configuration, but as soon as you start plucking people off, and adding other people to the team everything is up in the air again.

It’s also a bad habit to rely on it.

Yeah, my last gig had high turnover (not a coincidence with the dysfunction) and it made it particularly apparent that the estimates were a waste of time, but we kept on trucking.

Reply on news.ycombinator.com