There are places where the incoming work is pretty high volume...so you need a "ticket" system just to make sure it's all accounted for. Jira isn't perfect, but I can't tell if you just generally object to tracking work, or if the particular environment you're in just doesn't need that sort of thing.

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.

You seem to be talking about JIRA reports. JIRA != Trello + fancy reports.

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. :) )

> 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.

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...

You can also build flexible, low-overhead workflows using JIRA. The key is to keep managers out of the admin section, make sure the dev team is in full control, and tend towards saying "no" whenever anyone asks for changes to the workflow.

I think anecdotally that may work, but I'm not convinced that dev teams are that much better than "managers" are at creating or managing process (nor are they often very interested in doing it)...

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.

Just anecdotally I can confirm that different development and product teams work good with JIRA and Confluence in conjunction.

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...

> The key is to keep managers out of the admin section

Works as a general rule, too.

Apache uses them: https://issues.apache.org/jira/secure/BrowseProjects.jspa?se...

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

the companies that pay the foundation bills.

I shall steal the quote, "Rorschach number generators for management" xD