Jira is organization poison, not just a reflection of what an organization is.
JIRA in its default configuration essentially lets you create anything, anywhere in any state. Anything beyond that is just bad product configuration. Now, there are plenty of products out there that suck no matter how you configure it (looking at you, ServiceNow).
Especially the comments about "I would rather use trello" seem extremely uninformed as you pretty much *are* trello when you just stick to one kanban board and one project.
That's kind of the point, JIRA has been made into monstrosity at many organizations because the "create anything" mindset.
> it attracts somebody 4 layers up to tell somebody 3 layers up to come up with a common
with pretty much everything, including a spreadsheet or a plain text file.
Conflating bad business practises with tool configuration or products in general doesn't help anyone. If a business is very stiff and scared of its employees, they will try out all sorts of useless control methods hoping it will somehow make some metric 'better'. You can do that with Trello too. Doesn't make Trello a bad product, and it doesn't make JIRA a bad product.
At the same time, pretending a larger organisation with many teams can function without any form of state tracking is a nice dream but not a reality either, so it's not like you can do without anything at all. But like reposted a bunch of times, how you do it and who is responsible for it is pretty important.
Tools can't prevent bad management because bad managers don't care about tools. They care about getting what they want, and if the tool doesn't enable it, that's their underlings' problem, not theirs. Jira doesn't stand in their way because nothing stands in their way.
Given the amount of effort you devoted to replying to multiple posts, it feels disingenuous when you make an obvious and inaccurate statement as fact.
There is very little dependency graph organization (eg subtasks), which isn't reflected in most of the UI anyway as JIRA does push toward treating all tickets as a flat set. Work is a practical hierarchy of concerns and JIRA never made much progress away from a checklist (same as ASANA, Rike, etc).
"Implementors". Anything that needs to be "implemented" is either a) not finished, b) too big and complex, or c) both.
Dunno for sure how much less code Jira has compared to, say, MS Excel or Adobe Acrobat, but I could imagine it might be up to an order of magnitude. But you don't have to "implement" those; you just install them.
But no, that's missing the point: That's what makes it an equally stupid "Enterprise product". Excel, OTOH, is arguably more essential to more corporations, and yet you don't see big international consultancies snap up contracts for six-year-long "Excel Implementation" projects with Fortune 500 corporations. You do see that for SAP, Oracle Business Suite (or whatever it's called nowadays), etc. They're products that you don't just install and use; they need to be "implemented". JIRA is more like that.
Or, IOW: I wasn't comparing, but contrasting. (Which, OK, is also a kind of comparison. But for this kind, it's Excel that is the better example than Teams.)
Eventually somebody with the organization obsession is going to get hired and put somewhere important and their goal is going to be making something complicated and unified and dissent will be "discouraged".
On the other hand, like almost copy-pasted here, if a top-down 'unification make it worse for everyone' effort is started, no vendor or tool is going to stop that and your work will get worse.
My guess is it's because Jira actively targets SMB, while ServiceNow is almost strictly enterprise, and folks in enterprise have already resigned to their fate.
We dropped SN a couple years back over this. They were charging us about 6-7x what we pay for Jira, and we still use the on-site enterprise version of Jira.
Usually, if it isn't better from a staff-perspective or better for the customer, self-hosting or self-building is less likely to be the answer these days.
Having a Service Desk that actually provides usable and composable tooling is a benefit for all. Having a random contractor "implement" ServiceNow because Gartner said so is a pain for all. This is of course a bit of opposing extremes, but the same applies to JIRA and AD and pretty much anything else. Hard-pushed bad implementation will ruin your workday.
Teams that are capable and allowed to self-steer and deviate from company policy if they come up with a good enough reason seems to be the sweet spot of attainable & realistic.
That's the problem with any tool, framework, language, etc where the defenders main argument is, "It's great as long as you don't abuse it." or to put the former bluntly "It's not the tool, it's your organization." Over and over and over again, if an organization is allowed to abuse and misuse something, it eventually will.
Good tooling has opinions and will give you guardrails to not hang yourself.
As organizations and projects grow you or someone else will at some point hire incompetent people that mess up this delicate balance.
Better to have guardrails.
Customizable, absolutely to a fault. It is the infinite customizability of a tool targeted towards middle management which is why Jira can go to hell.
It is indeed possible to not be in Jira hell, but inflation of complexity is inevitable and almost entirely irreversible. It encourages and accelerates the path towards bureaucratic hell. Any avoidance of this is a temporary aberration.
I though so too, but now I no longer believe that's the case. This is because of two reasons: one questions the statement itself - and the other one questions whether the statement correctly identifies the organizational issue.
Firstly, almost every tool I ever used for project organization has grown to similar degree of complexity. All _software_ employed was strongly incentivized to implement new mechanisms of automation and regulation - thus right now I would struggle to name a non-defunct and non-single-user tool that doesn't have the issue. And certainly no tool that that I would call "established" - an arbitrary designation, to be sure, but that largely reflects that the complexity almost _defines_ establishment for a project management tool.
Secondly, because I think the issue isn't, truly, the _bureaucracy_. Right now I believe it's the _technocracy_. It's the belief that every process has to be codified into software, and enforced in a manner that would make exceptions impossible without a pull request. This leads to - increase in complexity (because corner cases that would be easily solved with a quick email exchange now require weird workarounds - and if they are too common, actual change to the software) - reduction in real organizational flexibility (any special case is now discouraged on a technical level).
Worst part is, it's very hard to sell a shift away from this. Technocratic adherence to software-enforced processes became nearly synonymous to "accountability." In itself that's frustrating to me - I believe this serves to paint organizational failures as forces of nature, effectively reducing accountability. But, so far, I have failed to effectively communicate it to most people - with exception of the very few who, themselves, have a considerable interest in social dynamics, one that goes beyond the professional interest expected of a manager. And to those, those are generally truisms - I'm under no impression I'm particularly original here.
---
Aaaanyway, I went back to liking Jira - because, under all the cruft, there's still (or at least there still was) the basic bug tracker software that's almost like Bugzilla, but slightly less painful. And I like bug trackers, as long as they're used to track bugs - not manage projects. Projects are managed by people, and these days I believe that the reason all this software, as complex as it is, keeps failing to accurately communicate the project state, is because you would need the software to be a person.