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