Agile is not supposed to make development faster. The core element of being agile (small "a") is to avoid doing work that results in features that are hardly used, not needed, etc. In lean terminology this is called eliminating waste in a process.
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.
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.
JIRA is a form of Stockholm syndrome. Your life truly sucks if you think that makes it better. Some of the least agile places I've worked in used it (over-used it really). To be more agile, ironically.
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.
One issue is that many many ticket management solutions suck a lot more that JIRA.
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.
i mean, i never said jira was good. i said that it was not as bad as azdo.
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.
I used to think JIRA sucked until my company migrated to ClickUp. In general most of the tools can be made to be usable if a tech lead or engineering manager can tweak them to what a team actually needs. Usually they are left in the hands of TPMs or Scrum Masters who generally make the whole process too heavyweight and complicated.
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).
> Usually they are left in the hands of TPMs or Scrum Masters who generally make the whole process too heavyweight and complicated.
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.
Having been inflicted with both, I agree that if I have to choose between the two, Jira is the lesser evil. Azure devops makes almost anything else look great by comparison.
Over-configured Jira is so much worse because it only gets slower the more configuration happens and some sorts of managers love top-down micro-management and force wild workflows that make no sense other than for wasting time on red tape.
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.
The goal is fine-grained alignment with your customers or stakeholders. In the long-run this should make product development more effective, though it's probably not going to be the fastest way to accomplish any individual task.
Less waste literally means making things faster. See the problem with agile? All the jargon and stories that the agile tribesman like to build upon simple things.
I guess define "faster". If it means getting to product/market fit earlier, agile is your guy. And that could mean eliminating waste so much that it's just 2 devs hacking on an mvp, testing it with real users every few days / week, adjusting the mvp to solve the users problems better each time, with 0 distractions.
If it means delivering features faster, whatever they are, to make an executive feel better, agile will not help you.
Not really. Less waste means not spending time on non-essential features. That doesn't mean that the core features people are focused on will go any faster at all.
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.