Even the original waterfall model empahsized on feedback, feedback of design, feedback of usage https://en.wikipedia.org/wiki/Waterfall_model#/media/File:19...
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 "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 you aren't allowed to do anything if there's no Jira ticket, you just created a lot of process friction to get anything done. That's a great way to weed out things like independent thinking, initiative, and pro-active thinking. Jira is the perfect digital idea shredder.
Add approvals and nitpicking middle management and we're back to the good old days of people asking for TPS reports. Which is an Office Space reference, a satirical movie from the pre-agile era (25 years ago). Replace TPS reports with Jira ticket and you got most scrum sweat shops covered. It's uncanny how on point that movie still is. If you think things are different now, go (re-)watch that movie.
Organization wide agile is not a thing. That never really caught on. Processes like scrum are designed for small teams. Attempting to coordinate that with 100 teams is hard. And mostly futile. I've seen the results of companies that attempted this; not pretty. I once attended a sprint planning with 14 teams from all over the world. Because flying them in was expensive they only did that four times a year. So, to get anything on the agenda you needed to plan months ahead or you'd be too late. The agility of an oil tanker. I never saw so many postits in my life. All backed by Jira of course.
Most large companies have no such thing as company wide sprints for the simple reason that that's not a great way to run a company. Mostly they still operate the same way they always did: on quarterly and yearly reporting and targets. If products involve more than just software (like actual hardware of physical goods), that tends to dictate the planning.
i used to think the same until i had to use azure devops.
i legitimately miss JIRA nowadays.
CVS isn't good because Visual Source Safe exists.
As an analogy, it feels the same as saying "git sucks", and going on a journey to try CVS, SVN, VSS, DropBox's version management, Apple's TimeMachine, Synology's file management etc. to discover the strength and weakness of these random solutions one by one.
At the end of the day you end up really liking git, but when telling to people that git is really great you're met with grunts and middle fingers.
And that's the issue most people on this thread miss. If every tool for reaching some goal suck in some way, do the best of them really suck?
after 17 years working as a dev, i came to the conclusion there's no good ticketing system, there's only less-bad-ones. and i honestly think a well configured jira instance is the pile-o'-shit king.
Our team used Redmine from a decade ago, but people like all the pretty ways to drag items between columns or something
i worked at a place back in 2008 and we used redmine -- i even wrote a plugin to track worked hours so we could properly bill clients (i ended up learning rails because of this).
You got me looking, but this doesn't seem to exist. I kinda want to see a Calvinball issue tracker now.
This is what happened to us for years, trying to create a common process for multiple teams on the same jira project. Then the manager that oversaw those teams left and during the last reorganization we all split up into our own jira projects where each team could configure it however they wanted. There's still rough edges, like with how links are inconsistent, but overall it's been pretty great since then.
I had to eat my shoe on Jira, railed on it for 10y easy.
Once you find a workflow requirement complex enough, very few things can do what JIRA does, including configurability.
Hiring a senior experienced JIRA consultant made a huge difference.
Other options look nice until complexity explodes.
Given the (forced [0]) choice I'd rather use unconfigured Jira than configured Jira. The mysterious "well configured" Jira is a Goldilocks zone that I've heard theoretically exists but have never once encountered in the wild.
[0] If the choice is Jira or a gun to my head, for instance.
I hired a single Atlassian consultant, and after taking the time to understand things, he delivered something that shut my opinion up about JIRA.
Like you are implying, every company can be different, and tools like JIRA have many ways to get the same thing done.
Still, since JIRA self-hosted version has gone away, there is opportunity for something new to cover it's feature-set in a new way.
You can carve a guitar neck out of a single large piece of wood, but 60% of that piece of wood turns into waste.
Or you can glue three much smaller pieces of wood together, and 5% of that wood turns to waste.
It takes longer to make less waste.
If it means delivering features faster, whatever they are, to make an executive feel better, agile will not help you.
Someone (product owner) should be prioritizing the core things needed to be delivered which means you don't waste development and testing cycles on things like an extra button on the MS Office ribbon bar that does a hardly used feature.
Smaller iterations of deliverable work prevents a big up front design and putting in features including UI designs, software designs, coding, tests, QA testing, etc. and then it doesn't get used or has minimal ROI.
JIRA sucks. If you think your issues with delivery are tied to your work tracking system then you're looking at the wrong things.