Well, it is neat and it does look like Trello. And Trello is now part of Atlassian.

If you haven't noticed the chorus of trashing Jira for the sake trashing Jira in this forum you aren't reading it. It borders on the hysterical. A large part of this crowd believes they have an objective handle on cognitive bias yet most of the Jira commentary seems to come from the subjective experiences of developers who simply don't like having their work organized or fixing bugs. Jira is the most extensible, best platform of its type for workflow management & I would argue (without at all being linked to Atlassian in any way other way than having seen it succeed in numerous disparate use cases) that bad experiences with it are the direct result of not having any idea how to use or configure it correctly to model the work being done.

That's all well and good, but being a foot soldier engineer in a big company, I don't have any influence in either how it is configured or how the work is being modeled. I just know that the page loads took multiple seconds and converted a sub-minute task of updating status or checking information into a multiple minute task.

I tend to track my personal workload in a text file at a more granular level. When my team's project was approaching a deadline and a crunch and I needed to stay synchronized with the developers working closely with me, I transcribed this list to Trello. I showed it to the PM as a curiosity and the next day all of the cards had been printed out and affixed to the wall with masking tape. That's the type of environment a lot of us are working in.

The problem with JIRA is the culture that it encodes and enables. It's rooted in the belief that programmers are factory line workers who aren't smart or organised enough to keep track of their own work, so invariably control of it gets assigned to a "project manager" who then spends far, far too much time engaged in busywork. You end up with hard-coded workflows that don't match how people actually work and the people who need to actually use the workflow get frustrated.

Fundamentally JIRA is an over-grown bug tracker. A bug tracker should be designed, built, administered and used by programmers and only programmers. Project managers should not even have access to it, in my view, let alone try to use it to create reports or control the team.

Typical problem I face in my JIRA shop: there'll be no way to move a task straight from "to do" to "done". You have to move it to "in progress" then "in review" then "in qa" then "done", even if in fact, the ticket just tracked the need to do a quick code cleanup that happened to get done as part of some other task. There's no justification for this type of thing beyond over-empowered project managers.

You believe that Jira has "encoded" that culture in your company, not that your company has encoded it's crappy culture in your Jira implementation? Please see: https://en.wikipedia.org/wiki/Conway's_law

Yes, "encoded and enabled".

I saw how that culture evolved over time as the company got bigger. It didn't start out that way. JIRA was once a bug tracker for us. It became a some sort of flowchart madhouse with horrifically convoluted processes around it. Partly yes, because the company felt a need to hire project managers, and partly because the tool existed and therefore there was something for them to fiddle with all day. If they didn't have the tools to create over-engineered processes, it would be less likely to occur.

At some level, yes, JIRA just enables problems, it doesn't directly create them. On another level, its whole structure encourages that way of thinking.

The main criticism I have been seeing is its performance, not that people don't like how it's being used.

Part of the reason people complain about jira is because their own company has tweaked it so much it became slower than a turtle and is riddled with all those random fields their upper management requires to make some meaningless reports.

>>A large part of this crowd believes they have an objective handle on cognitive bias yet most of the

Yet you claim because YOU've seen it work, everyone else must be wrong?? ironic ?

Jira Server is really hindered by the centralization of its workflow management administration tools. You cannot have "workflow admins" that can change issue type schemes and stuff like that for a subset of projects without giving them full admin rights.

Imagine having a guy in Dev that can fix your workflow so that "Start working" is not hidden in the dropdown menu.

I don't have to imagine it. This is a textbook example of a Jira implementation failure not a Jira failure: "not having any idea how to use or configure it correctly to model the work being done."

Personally I am quite familiar with configuring JIRA - and I agree it is very customisable... but, as many have said - it is far too slow.