Agile was meant to be "agile in change", not following tickets blindly.
It was meant to foster collaboration between people rather than putting every detail in tickets by whatever manager/PM. So people know why they are doing stuff, and can make change accordingly.
Agile was meant for making things that people actually use. Not about how many features were developed in last sprint.
I've had good tickets where things were laid out like 1) here's the golden path, 2) here's where I want you to put everything, 3) here's how we handle expected errors, 4) here's all of the interactions the user should be able to do
I also have had bad tickets that define loose acceptance criteria and leave it up to the developer to decide the UX, edge cases, error handling, etc.
The former removes a lot of burden of decision from the developer. It feels like the author of the ticket is showing ownership. I can mostly worry about how to implement it and not worry if my decision is going to negatively affect users that I'll get blowback from.
The latter feels like they are letting an assumed-to-be-smart person make more decisions on the product and that they're closer to an ideas person hitting you up to make their latest world-changing startup idea.
With the latter, the developer is taking on more responsibilities and accountability. They need to be good at development and also good at understanding the users and the product and UX. That's two roles in one if they're good at both responsibilities (they probably aren't), but the compensation is likely only around 1 job.
And now that developers are also mixing with operations/cloud management responsibilities, you now have a lot of groups of people hitching their wagons to what the developers do or think is best. Everyone is here to support developers so developers are now making a bunch of decisions in areas they aren't experts at.
Following tickets (almost) blindly should be an advantage. At no point should I get a ticket and have to ask the question "will users actually want this?" because someone else should be answering that and not a developer. Being able to deliver a ticket that a developer can follow (almost) blindly means that thought and care are going into the decisions about how to deliver something. It ultimately means developers can make decisions in the areas they are experts at, and other staff can make decisions on things they are experts in.
Edit: definitely not disagreeing with your post, just some thoughts on the issue
The "bad" tickets is where you actually bring value though.
The "good" tickets can be given to junior dev/low cost contractor/ChatGPT.
Whenever I read things like this I feel like a lot of developers don't understand what their job actually is. It's not just translating tickets to code.
If the people whose job it is to keep in contact with the customer and collect requirements don't know either, developer's guess is as good as theirs. Otherwise, individual developers may not be the best persons to decide all the details. You risk wasting time by doing the wrong thing either way.
Even the original waterfall model empahsized on feedback, feedback of design, feedback of usage https://en.wikipedia.org/wiki/Waterfall_model#/media/File:19...