If you can point me towards someplace visible that is using these tools well, I'm more than happy to be wrong. Every time I've seen them used, they're more like rorschach number generators for management, so I have naturally assumed that my experiences are the normal. That is, of course, a fallacy, so if you can point me to such a paragon of use, I'll be more than happy to check it out.

And, of course, it's configurable, so any local installation of Jira can be tweaked in such a way that it's a pain in the ass...or not.

I've worked places where there was a high amount of incoming work, and no tracking, and it wasn't healthy. Lots of "squeakiest wheel", "who is working on this?" and other issues.

The strength of JIRA is that if your company suddenly needs a different development flow (whatever it is -- new tooling, new workflow, more teams, awkward regulatory requirements etc.) then you can stay with JIRA because whatever you want to do will be possible with JIRA.

(Uh, I sound like an Atlassian shill, even though I dislike the lagginess of their UI and also how they handle Bitbucket. :) )

This actually seems to me to be the biggest problem with JIRA... JIRA allows for the creation of arcane processes that very easily become burdensome because JIRA is very loose in its opinions. And, on top of that, the management of that process also often becomes a burden for the same reason...

And you're also stuck carrying around all the features you don't use...

But I think this does get to the core issue with JIRA. Whether you "like" JIRA or not is more a reflection of your organization than it is a reflection of JIRA as a tool.

The agency I work at uses these tools together with ovur clients, as well as internally on different levels.

We have an internal project were we are just using tasks, subtasks with 3 states in a team of 9 in three to four locations. And we have a client, being served with about 100 people in different teams working on multiple projects, spanning multiple locations. Here we use the same tool. In one case with just a basic setup. One a 'little bit' more elaborate and customized...

Works as a general rule, too.

I am not sure who the 'management' would be in their case.

I feel like, as an industry, we should be moving beyond that at some point.

Now, if there was a way to grow its user interface along with the organization's growth, it would be fantastic.

Just throwing something out there... But I wonder what the spread of these "smart" people is across "development" and "management"? The parent comment seems related to this...

> JIRA is like Excel or Word -- 80% of people use only 20% of the functionality (or less), but it's a different 20% for all of them. And it's really-really painful to realize that Trello/GH Issues/etc. works great with a slick UI, except that it can't do that single stuff you'd really need because of your special situation.

Also, just throwing something else out there... But I wonder, at what point, do we stop building tools that can work for 99% of the use cases and start actually having opinions on which specific use cases are "good" or should be encouraged? Because, like some of the other comments have said, a lot of those workflows that "only use 20% of the functionality" aren't exactly appealing.

The "tool" doesn't need to be overly "opinionated" just like a programming language, I want a tool to be flexible. It's my responsibility as the architect to constrain the tool/language for my environment.