> Jira isn't inherently a better or worse tool than most others out there.

I'm not sure I can fully agree with this based on my experience.

When you talk about Jira being set up poorly, it makes me think about how workflows, permissions, project structures, etc are configured. This is definitely a pain point for me and I'm sure someone like yourself could bring a lot of improvements in this area. I fully buy that Jira is extremely powerful in this regard and it is possibly my orgs's fault for why it sucks so bad right now.

However, there are some other issues that I imagine are not so easily correctable. These pain points are mostly related to how the product integrates with other software - how slow it is, how cumbersome and nonintuitive the UI is, and how absolutely god awful the content editors are - particularly the wysiwyg editor in confluence (seriously bad!).

Maybe I'm off base here, so feel free to correct me. I'm sure you've had more experience with these products than I. However, I have used a lot of alternatives and from the point of view of a simple user, the Atlassian experience is not on par.

Overall I think you're correct, but I want to add some color to your comments:

Integration with other software is going to depend on a per integration basis. Some integrations are done by Atlassian themselves. Some are done by the other software provider. And some are done by third parties. Slack is a great example where the integration is owned by Atlassian, but there are also third party alternatives. The "quality" of these integrations varies, in large part depending on what your specific org needs. In the Slack example, the Atlassian integration has no support for creating issues in Jira from Slack. This is a use case that a small subset of customers want. Does that make the Atlassian integration bad? If you have specific integrations that you are frustrated with feel free to shoot me an email and I can dig into it. Especially if it is made by a third party provider, we're a really tight knit community and I can likely email their CEO and see if things can be improved for you. Or hell, it may even be one we make and something we need to fix :D

The UI is slowly improving, but yes it is not the most intuitive thing in the world. It is also a 16 year old piece of software, where if you look at the UI, the chrome has changed, but the structure has been fairly stable.

Performance is a topic near and dear to my heart. I have given a number of talks about this and for a long time our company branded itself as the "performance and scale" experts for Atlassian software. With good governance, and qualified admin skills, Jira and Confluence can be "fast enough" in terms of enterprise software. Will this be web scale speeds? No. Does achieving web scale speeds provide value for 95% of users? No. The thing to do here is to improve integrations to reduce the amount of application switching that users are doing. For example, if you're a dev, use Smart Commits[1] to interact with your Jira issues as part of the commit message. No going into Jira or BB in the first place.

The editor in Confluence has been a work in progress in Cloud, but they're hitting a lot of issues. Part of the issue here is that providing an editor that is both friendly to an HR person, and to a dev is a complicated challenged. When Atlassian deprecated Markdown from Confluence, I was working for them at the time and published the Markdown Macro for Confluence [2] as a ShipIt project (internal hackathon). This has helped thousands of orgs interact with Confluence via Markdown. At the same time, we're building a Drag and Drop editor for Notification Emails in Jira, and holy moly are there a lot of edge cases and problems that we hit. There are entire businesses that do nothing other than sell make and sell editors. I wouldn't underestimate the complexity involved in this.

[1]: https://confluence.atlassian.com/bitbucket/use-smart-commits... [2]: https://marketplace.atlassian.com/apps/1211438/markdown-macr...

Or maybe the problem with Jira is that bringing in an external consultant is the best recommendation.

Depends on what your timeline is for changes, but you can also learn how to use it and do it yourself.

My experience is that if an org decides to use <HIGHLY CONFIGURABLE TOOL> then they will do it wrong the first time without external assistance. This holds true even for popular tools like Postgres, AWS, Terraform, or even Git.

Anecdotally, I don't know of any tool that is highly configurable that makes it easy for users to set it up and then scale it over time without learning the specific domain knowledge. Jira is no different in that sense. If you have an example of a tool that bucks this trend, please share it, I would love to play with it and see what I can learn about how to better serve users in this type of use case.

I feel that Jira first adds a lot of restraints and red tape, and then makes those highly configurable. I prefer tools that don't have the constraints in the first place.

Ie if in the middle of the sprint a developer finds that some tickets are stuck waiting for some other team and he wants a column on the board to make that visible, he should just be able to add the column.

In Jira if I accidentally put the wrong issue in Done, I have no idea how to get it out... It's the complete opposite.

A physical whiteboard with post-its is rather good. You can use different colors, if each team member has one magnet with his/her name then it can't be on multiple tickets at once, you can draw lines and write words wherever, it's very flexible.

What an online tool should add, besides corona compatibility, is being a good issue tracker. Jira doesn't seem much different on that front compared to almost everything else I've used.

What Jira adds is lots of rules and constraints and imposed structure that gets in the way.

We are in the process of leaving it in favour of Github projects.

Re: the board thing, Jira has actually been trying to solve this problem for years now with a concept called Simplified Workflows. [1] This allows the project admin to create Statuses and adjust their workflow without needing to get a Jira admin involved. The problem with this approach is that every project does something completely different (often times even multiple teams within a project use different processes) and the people working to do higher level planning can't grok what is going on.

The rules get in your way, but as an entire org, they provide value. A lot of what we do is work with large orgs to actually enforce those rules top down on devs. The difference between our approach and most others is that while we agree with the idea of governance and top down rules, we drive the creation of those rules as a bottom up process. This way the devs get to agree on how they want to work, and as long as there is a degree of consistency, we get to tell management that this is the way forward, and we can now report on things while ensuring we're not getting in the way of the devs.

1. https://support.atlassian.com/jira-software-cloud/docs/use-t...

That's what we tried (our teams are self-organizing, as they are in Scrum, so we couldn't do it another way) but the things the teams wanted had hardly any consistency (partly because the products and projects are very different, partly because of the people).

This is where an experienced consultant can help. We often start with what you're describing here as the baseline, and then work to find a middle ground. I would say that 3/4 times we can find something that works for everyone. And it's ok that sometimes people need different workflows. Some Jira admins or managers trying to pull reports will be upset about this but they can be handled once you demonstrate why doing it this way provides more value to the org as a whole.

Make a status for blocked, create a column for that status

Yes but that needs to be part of a published workflow...

Large companies in many cases are systems in some local optimum of efficiency. If any part of the system improves, the overall system is worse off. Naturally, there is resistance to any change from the bottom. Change from the top is not done because they only perceive a cacophony of noise from below. Sometimes it is done in an existential crisis.

External consultants are kind of an organizational hack. In contrast to top management they can take the risk of being wrong. In contrast to the workers they are not part of the inter-department politics.

Jira Classic? Perhaps.

Next-Gen Jira is very 'hand-holdy', it's pretty straightforward.

I think you missed the parent's "+ other related tools". My company uses Jira plus Confluence plus Bitbucket, which are each more or less shitty, but they are more or less interlinked. And that interlinking does actually add value. It doesn't matter whether Jira is inherently better or worse than anything else. It doesn't matter whether an isolated Jira installation could be replaced with something else. The network effect keeps us locked in as well.

I did not miss that portion. I wasn't addressing moving away from Jira. I was saying if you don't have a choice in tool, and you're unhappy, then the path forward is to make the experience less bad by getting someone (more experienced/outside your political structure) than your current team to help you.

Jira, Confluence, Bitbucket. By looking at their interfaces and how they are linked to each other technically, you would think they were made by different companies and hacked together after the fact.

We just moved away from Atlassian to JetBrain's YouTrack. Huuge improvement in usability, system administration, cost.

Personally, I don't mind Kira. I also work at a megacorp that uses Jira and the idea that if I found something ten times as good as Jira I could somehow get the organization to switch just strikes me as absurd. We're too invested in Jira. Too many people using it. Too much internal stuff built on top of it. Change is unthinkable.

As a user (ignoring fixable things like our admin set up a state-machine for tickets so you can't move story more than one state at a time...) I mostly just hate that the UI is slow and I can't use Markdown like I can in GitHub and Slack

I had the same "state machine" style workflow with something like 6 steps in it. Combined with the slow load times and clumsy interface, I once calculated that it would take me several hours just to move all of my assigned tickets at the time from state 0 to state 5. Fortunately I was able to switch to a workflow that made more sense.

I feel the two types of problems you mentioned form a feedback loop, each making the other more painful.