Hacker News new | ask | show | jobs
by vertigolimbo 997 days ago
You can make it as useless and as powerful as you want. I have worked on many projects and developers loved it (no joke). But it was down to having it properly setup and using just the bare minimum that enabled to do work. What often happens, is that JIRA "experts" (usually incompetent PMs or Scrum masters) let JIRA dictate your workflow. That's where discontent arises. (No affiliation to Atlassian).
3 comments

You can make good workflows on Jira, yes.

That doesn't fix the horrible UX, sluggishness, confusing options, forms that present a lot of useless fields but don't give you the option to present other, more useful ones, ... I could go on.

Jira is a terrible tool.

Sounds like your experience mostly revolves around older self-hosted JIRA versions?

The UX on modern JIRA has been fine for years, and the options and forms are easy to use. Granted, you can add useless restrictions and weird field configurations, but if someone configures it until it's broken, that would be on them, not really on the product.

This is so divorced from my experience. The only Jira setups I have been with that worked were ones where we were actively diminishing its use in the company.

Small companies where only a small(er) unit of people use Jira (cloud) is fine, large teams, large workflows, selfhosted or cloud: doesn’t matter. It was always terrible.

We actively discriminate against Jira in our company at the moment, and for us it works pretty good. But that is because it is not essential and we do not lean into it.

We don't have any instances with more than 500 users so perhaps that's the key difference here. We also don't have any PMs or 'admins' that do heavy handed top-down "you must use it this way" configuration.

We do have all product owners meet up at least once each month and the project collaboration methods are often on the agenda to make sure we don't end up with too many different workflows that are essentially duplicates of each other. Besides the workflows (mostly oriented around kanban boards and backlogs) we just make sure that collaboration across teams use compatible workflows and epics so you don't have to copy-paste information and instead just share stuff.

Each individual team is no larger than 8 people, most are smaller.

I worked at a company that bailed on a JIRA Server to Cloud migration and went for enterprise instead because cloud's performance was so poor compared to the self hosted version.
We did have people actually migrate away from JIRA because they didn't need the features, not really because they were required to move to the Cloud instance. But the fact that they now had to move at all made it easier to switch (some went to Redmine for some reason, others went to Git-SaaS integrated boards).
I haven't used a self-hosted Jira in many years. This is for the SaaS but IIRC it's not any better on self-hosted.
Strange... While I have seen many poorly configured PM tools (including more badly configured JIRAs than useful configured JIRAs), I haven't really had any performance issues or UX issues with the ones I work with directly. It's not 'slower' than say, GitHub and GitLab's boards, or Trello.
I used to work for Atlassian (not on Jira) and the Jira "experts" that worked there set it up in such a way that everyone there hated it too. If your product has such bad defaults and is so flexible that this can happen, you've made a bad product whether it's technically possible to use it right or not.
Defaults matter, and flexibility can be bad. Apple really gets this.
Unlike most IDEs, where using more of the tools means better productivity, Agile project management doesn't benefit from more features and capabilities. A memory leak finder or profiler or better lint has no downside.

Not true for project management features like, for example, "velocity" measurements denominated in story points (unitless) over time (seconds). Management metrics bullshit seldom benefits a project. In feature-monster tools like JIRA you have to do a lot of work to un-feature a project and those features are still lurking.