The agile stuff in particular feels like a bolt-on. Its obvious that JIRA grew up from a simple bug tracker to a complete software development workflow engine. The pain points of its growth and add-ons are frustratingly obvious. It really needs a reboot.
I feel like Atlassian products are vulnerable to be picked off. There's going to be something that kicks it off its pedestal soon. Good riddance.
Unfortunately, most of the tools out there don't scale well, so most teams reach the point where Jira is the only reasonable choice.
(Full disclosure, building https://clubhouse.io address this problem.)
There are at least 5,000 for JIRA alone: https://jira.atlassian.com/browse/JRA-161?jql=project%20%3D%...
From my experience, and those who have watched issues for ten-odd years, I'd say the opposite is true, but I'm not working on a competing product.
"Biggest issue I have with Jira is how it's trying to be the everything tool for all processes and procedures"
JIRA didn't try to be a universal tool for all processes and procedures, but it happened to spread from the development team into other parts of organisations due to it's flexibility. Of course that flexibility comes at a cost the experience to the end-user is controlled by the administrators.
What is the alternative? A more opinionated tool could potentially get a specific task done better. The problem is that you will need 2, 3 or more separate, more opinionated tools to cater for the specific use-cases. These tools will have to be maintained and probably won't integrate very well, making collaboration between different departments a lot more difficult. That's exactly what JIRA tries to solve, help your teams collaborate.
Could Atlassian be more opinionated. Absolutely. Being opinionated doesn't necessarily mean that we need to limit the flexibility of JIRA. We can do a much better job at optimising for specific use-cases and guiding people towards best practices, while still allowing customisations where desired. We've started this effort last year by introducing JIRA products aimed at specific use-cases. Take JIRA Software for example, it's aimed at Software teams and has specific features like Scrum, Kanban boards, sprints and releases that are specific to software teams. If you aren't a software team, you can just use JIRA Core and you don't need to worry about what Scrum even means.
There is a lot more we can do to make the simple things simpler, and it's a big focus area for us. We won't enforce limits on the number of fields you can add, but we are looking at giving project administrators a lot more autonomy around how their projects are configured. We can't stop the QA checkbox from appearing if somebody really wants it there, but we can provide the guidance and tools to make the experience better for everyone.
Happy to answer any questions you may have.
1. maintain parallel excel (or whatever) sheets and have all these different managers manually bugging the developers and qa people constantly to keep it up-to-date, or
2. stand up parallel systems to track each of these things with varying levels of integration, and as a developer you now need to remember to both close the issue in your bug tracker AND update this project management dashboard AND update the security status tracker AND add a ticket to another system to get the end user documentation updated AND on and on...
When you've worked with that kind of system, you start to long for the simplicity of another field in the issue tracker.
Whether or not this is Atlassian's fault is debatable of course. I feel like they were more opinionated back when I started using it ~10 years ago (with the Greenhopper plugin). It was a much, much more pleasant thing to use. Probably because it was only under the control of the teams who were actually doing dev work.