I have spent the past 20 years cultivating a variety of tones in which to utter my standard reply to such nonsense:

"Cool. You do it then."

Yup. Not getting paid? Don't work.

Forced to? We have a word for someone who is forced to work for no compensation.... The word is slipping my mind, but I'm pretty sure the USA fought a civil war about it.

The estimate is not a promise, it's a guess. I prefer to estimate in sprints because that's about the resolution we can have confidence in, but management want hours so my process is to estimate the number of hours in a sprint (73.5 for us) plus one sprint

200% overruns are common, especially when requirements change significantly

Wildly depends on the complexity of the feature. If it only takes 4 hours to implement, you might have good enough of an idea what needs to be done that you can estimate it with 1-hour-precision. That is, if you're only doing things that you've done in a similar form before.

If the feature takes two weeks to implement, there's so many steps involved in accomplishing that, that there's a high chance for one of the steps to explode in complexity. Then you might be working on it for six weeks.

But yeah, I also double any estimate that I'm feeling, because reality shows that that ends up being more accurate, since I likely won't have all complexity in mind, so in some sense my baseline assumed error is already 100%.

Disagree. My company does it well and I think it helps productivity across the board. My last job called our process agile and it was really just water-scrum-fall. Which was horrible and we devs were all miserable.

I remember when I first read about AGILE. I was like "this is pretty cool - but there's no way corporations will actually adopt this methodology without completely turning it into just a set of new names for the same shit they've always done." Naturally, that's exactly what happened.

Except traditional management is about removing as much power from the people that actually do the work as possible, so that's why this bingo even exists.

My job uses Safe. It's the bastardized scrum you speak of.

Are points the complexity, effort or time? Yes. No. No. Maybe. Yes. Who knows?

They also sum our teams capacity as if we are interchangeable cogs doing the 1 same simple task.

We have endless meetings. Daily 1hrs. Follow up to the follow up. Meeting to plan meetings. (I wish I was joking on this next on) Planning meetings to plan for the upcoming planning meetings.

It's chaos.

It's hell.

I get 5% as much actual work done as I used to. Not even joking. It's bad.

It's me, I do it. But only when I need something to do to stay awake in hour five of today's meetings to address the "quick turnaround" patch that I finished coding three weeks ago, but now they want a label to change and no one on the six teams that have somehow become involved seems to know who owns the package that the field the label represents belongs to, but they're absolutely certain we need to programmatically retrieve the text in case the package owner changes it at some point, and someone remembers that the original developer wrote code to get the label text 16 years ago, but it was removed from the program two years before the project started using source control, and they have an old installer around here somewhere that we can decompile or trace with Wireshark to get the right RPC name (sharing their screen while they have a rummage for it, natch), and someone else volunteers that they might know how to get a version of the server application from around that time since the client and server versions have to match, but it's technically the intellectual property of a different subcontractor who was just a guy in Alaska who passed away five years ago, but they're sure they can convince his estate to burn it to a disk and mail it to me if they can just find the contact information...

The person who wrote it has been gone for like four years

Four years? You gotta pump those numbers up. Those are rookie numbers.

Bikeshedding is when instead of making important, compex decisions that have consequences for being wrong, someone focuses on the simple, low impact, minimally important part of a project that has no consequences if its fucked up.

I think the term comes from construction projects where instead of finalizing the design of a complex building, the execs spend the entire time talking about bike parking on site. What color to have the roof, how many bikes it should hold, etc.

Bikeshedding is about offloading responsibility while still feigning involvement. You, the owner, avoid the whole part of your job youre paid for, i.e "making the hard decisions" and through misdirection and inaction, make someone else do it. That way you can blame them later if things go wrong, or take credit for their work if they go right.