[kasey_junk]

JIRA in its out of the box configuration is an adequate issue tracker. Thats never the problem. The problem falls into a few broad categories:

- conflating how you interact with issues (bugs, security events, new client on-boarding, etc) and how you do product development (prospecting, requirements analysis, systems design, etc). These activities only have a passing relationship with each other. Designing new products is fundamentally different than dealing with customer service items. Just as a specific, issues in JIRA are a terrible way to capture the vision and mission of a new feature. They are further a terrible way to capture requirements which in any other system would be versioned along with the software they define.

- the customization of workflows encourages teams to think of every component as a fungible unit. If you don't define 'workflows' and instead prioritize around results, you can motivate teams to operate in their best ways. If you build complicated or bespoke workflows in JIRA you operate in a way that presumes that all teams and all situations can be put in the same box.

- JIRA, especially in its most customized versions, implies that you can replace normal human communications, conversations, emails, chats, with a Platonic ideal of tickets. Yet tickets are a bad mechanism for spreading big picture ideals and an even worse mechanism for spreading specific details of a functional specification (no testability, no atomicity with software change, etc).

- JIRA's customizability leads people to think that the right thing to do with their project management teams is to define standardized workflows, automated integrations, normalized schemas for issues, and the like. Instead of doing the hard work of aligning priorities Project Managers get caught up in the minutia of making sure tickets are in the proper form or that developers have moved tickets through the correct statuses.

All told, this is one of those cases where worse is better. A title, a comment box and a set of tags largely allow you to systematically capture everything you need to capture and allow a qualified project manager to do their job. Github issues does this, JIRA out of the box does this, Bugzilla and FogBugz all do this. I only ever run into problems with JIRA, so I can only extrapolate from experience that it is something about JIRA that leads Project Managers to spend less time with legal pads and more times futzing with JIRA.

[chii]

all of those problems you have aren't inherently a problem with the Jira product. They are organizational problems, management problems, and communication problems. If you have any of those problems, replacing Jira with another issue tracker will not solve it.

Jira gets the flac, because but the problems isn't Jira.

[donkeyd]

> Jira gets the flac, because but the problems isn't Jira.

I recently had somebody come up and tell me: "I can't get a grasp of the status of the sprint because of Jira."

The issue, in stead was that people were creating epics all over the place and nobody ever updated their stories. So there was no clear structure and the burndown never burned down. I've worked with Jira for a long time and I can, almost, always adapt it to fit a process. However, when nobody knows that the process is, it's impossible to create a good version in Jira, but Jira ends up getting the blame.

[closeparen]

JIRA makes it dangerously easy to implement overly bureaucratic processes. A certain kind of organization is drawn to it for that reason. Even a healthy organization switching to JIRA can get carried away with the tools now at its disposal.

JIRA is a software product but also a social institution, an organizational philosophy. Sure, you can have the software without the attitude or vice versa, but use of JIRA is still a (weak) negative signal about the quality of an employer.

Turns out that the main thing protecting employee autonomy is the logistical difficulty of micromanagement. JIRA "solves" that problem.

[wonderwonder]

So your argument is that JIRA is too good and gives the user too much freedom to do what they want? Software is a tool, it is there to do what the user wants, a good tool does not limit the user. Organizational processes are just that, those selected by the org.

JIRA is successful because it is a good tool that gives power to the users. Anyone is free to build a competitor to JIRA, but I would argue that if the developer limits it and forces the client to use their preferred process methodology that they will likely fail.

Just my opinion. I have only been using JIRA for a few weeks now, have had no issues. Nothing amazing about it and nothing terrible. It does the job. Its just a tool. How its used is up to the user.

[closeparen]

“The user” is not a monolithic entity. JIRA transfers power from labor to management. Obviously a certain kind of management loves that, but as a worker, it’s in your interest to stay away.

Of course you can use JIRA as just a tool, but it tends to take on a life of its own, becoming central to his work is allocated and performance is assessed.

[castlecrasher2]

I agree. One of my previous companies used Jira and it was absolutely fantastic because one project manager had a clear vision for it and implemented it and the other PMs planned sprints inside it.

[MisterOctober]

Yep! I switched to Jira from an older in-house solution early this year, and have found it to be excellent so far. There's a little learning curve on the admin side, but the actual experience of using it for feature / issue tracking has been real positive.

A lotta folks I talk to have had bad experiences with Jira in a big-company setting -- say in particular, Amazon --- but most of those problems I've heard boil down to poor practices on the management / admin end, rather than problems with the software itself.

p.s. I've also used Asana and a few other less-costly solutions, but their limitations ended up getting frustrating.

[Klathmon]

yeah i've just recently started heavily using it for the first time in a few years, and it's not bad!

It has a fair share of issues (it's SO SLOW to do just about everything, and the text editor annoys me to no end!), but overall I think it's making me more productive and it's a lot easier to keep track of what i'm doing, what i've done, and what still needs to be done.

[hvidgaard]

The old saying: Too many chefs spoil the broth. If you have multiple people with conflicting priorities the tool will be crappy.

[derefr]

Other issue trackers "solve" the problem in that they're technically incapable of faithfully representing objects like design specifications, adding enough friction that the process is pushed back from "technical solution" land to "social/organizational solution" land where it belongs.

Jira is a crutch, in the most literal sense: it makes things that should be hard because of your lack of {personal, organizational} health, easy, in a way that makes people avoid doing the "healthy" thing (facing their problems and rebuilding said {personal, organizational} health) indefinitely.

[kasey_junk]

But most other systems don't sell that they can solve this problem. If I gave you a web form with a title, a description, a comment section and some tags, would you argue that you could solve those org problems?

Would you spend any time trying to solve the problem in the system?

[chii]

> But most other systems don't sell that they can solve this problem.

Don't the simpler (more opinionated) systems also tout the same?

All software is sold with the same promise in one way or another.

[CamouflagedKiwi]

Agreed that the problem isn't directly Jira, but (anecdotally maybe) there seems a clear correlation between Jira and unhappy developers who feel their tracker has way too much process. Jira doesn't cause the root problem, but Atlassian are profiting from it existing, and so maybe people are encouraged to use it in those ways. I'm not letting it off the hook so easily.

[joeblau]

The product gives users all of these features that are easily misused and misunderstood and that is the problem with Jira. It's an unfocused product.

[regularfry]

That is precisely the point.