The times I've see it used, Jira is purchased and configured by centralized people with institutional authority, and then given to teams to use, like it or not.

I think the tool itself isn't that great. When you try to be all things to all people, it's easy to be tolerable for most and great for nobody. But the real problem is what it represents: a straitjacket for teams, used to force them to work in ways that people with political power deem appropriate.

The Lean Manufacturing folks put bureaucracy into two different categories, supportive and controlling.

Supportive bureaucracy is bottom up. E.g., by my door I have checklists for what I need when I'm going out running or swimming. Nobody makes me do it; I just was tired of forgetting something. Good teams do similar things, like an estimation checklist or a written-up release process.

Controlling bureaucracy is top down. It's where other people use systems to force you to work like they think you should. They're used as a poor substitute for trust. People experience Jira as sucking because it's a instrument of control, and controlling bureaucracy sucks.

I don't know. It's fine for keeping tasks but seems quite slow.

Just clicking on create issue takes 4 seconds. Switching between issue types takes about 1.5 seconds.

This should all be just simple javascript change and layout calculation but there seem to be network requests for every single click.

To me, that sucks a little.

I've both loved and hated JIRA. For me, it all comes down to how well set up it is. Its configuration over convention approach leads to many installations being poorly configured and often hacked together.

I think people associate JIRA with middle managers who "work" all day in JIRA and foist draconian JIRA "processes" on everyone. eg: My current manager wants us update all open JIRA tickets every morning with "current status" .

Not sure why manager types like JIRA though..

I hate JIRA, but I noticed something. If I tell people to do something, they won't do it. If I create a ticket in JIRA it has a much higher probability of getting done. It's not been too bad, after I got over the hate of not having real markdown and the 100 fields when a ticket is created that are mostly unused.

I prefer little to no process, but the work has to be organized some how, and using git with emacs and org mode wouldn't be nice to most :)

Not sure if you've seen the org JIRA integrations, but you can effectively do ticket management in org-mode.

Among similar tools(HP Quality Center/VersionOne/Redmine/ServiceNow/Bugzilla/Trac) I have been using at work for the last few years, Jira has always been the most intuitive and user-friendly, at least from the developer perspective. The others might have caught up with it by now, maybe there are new better alternatives(please let me know about them) but I agree with the author that the most of the criticism comes from the people who tend to associate the bad processes they are forced to follow at work with the tool itself. Of course the downsides of Jira mentioned in this thread are all valid, but I don't think they outweigh its benefits.

I dunno if Jira sucks, but the granular subtask hour estimation it encourages certainly does.

Is this really how most 'agile' shops work in this industry?

Not that I'm aware of. Most Jira shops I've worked in have disabled that field entirely.

Any good resources for convincing management that this is a useless practice with absolutely no benefit to real-world estimation or productivity?

I would approach this differently. The question to ask is, "How can I convince the manager who has authority to make change X, that switching to Y will benefit him/her personally? How can I show them that the change will decrease the hassles in their life and/or lead to higher compensation for them?"

Ya I guess..

Was looking for something more along the lines of "PM at [cool unicorn] says none of the cool kids do X anymore" but maybe that could work.

Other than finding out about that practice in the interview stage and using it as a yellow flag suggesting that it might not be the job you want? Not really.

Either management understands software development or they don't, and it's not something you can really teach them either. I don't need my managers to know our stack or even be capable of developing working software themselves, but it's hard for someone who's never spent 6 months working in the coding trenches to understand the amount of uncertainty inherent in software development.

Ya, so it goes I guess. Was actually looking forward to something more organized after having no process to speak of for a year. And it's not even like the estimates get held over my head much or anything, just that putting in sub-tasks for..

1. add input box 2. create functionality to store input box value 3. have next page display value

..and keeping track of the time spent on each step is reeally annoying.

Having used other issue trackers over the years, Jira isn't exactly a shining beacon of excellence. The UI is hard to navigate, the screens are inconsitant, the JS breaks on occasion so buttons stop working, it's slow, has horrible defaults and is far too flexible in some areas but miserably inflexible in others (usually where flexibility would be useful).

All in all, it's not a great product. It can do the job, most of the time, but costs a lot of time (and therefor money) to get it set up even close to adequately.

Jira is indeed a tool, and it can do the job, but in comparison with other tools that also do the job, it costs too much for people to stop saying it sucks.

I haven't seen an install of Jira where opening dashboard won't take five seconds and any search will take ten.

I just don't see how it is acceptable in 2017, with added insult that the amount of data displayed is tiny.

In my case, opening a Dashboard takes 2 seconds and searching the full DB for text takes also 2 seconds. However, we only have about 2000-3000 issues in various projects in our DB.