Yeah I've been defended Jira here in the past, too.
My opinion is that Jira reflects the organisation that manages it. It's basically a whole lot of customizable UI and permissions hanging off a user-defined state machine. You can set it up so that individual teams can fully administer their own projects, or you can go all the way in the other direction and have centralized, locked-down management where you beg some internal specialist Jira admin(s) to make your changes.
Also, in the last couple of years it's got a lot better. It's faster, there are options for simpler configuration, and more stuff out-of-the-box (assuming you're on Cloud, but isn't everyone these days?).
In detraction: configuring it can be a huge PITA. So many screens, concepts, and so much clicking. But when it's done it works, and I think most of the hassle is just inherent complexity from such a configurable tool (if you haven't Admined Jira: you can change almost anything).
Jira doesn't just reflect, it drives convoluted unhelpful bureaucracy. The tool drives the organization to look like the tool wants it to, which is disorganized half broken "organization" with silly overcomplicated rules that give people something to discuss enthusiastically instead of the actual work that needs doing.
Jira is organization poison, not just a reflection of what an organization is.
No, it isn't. We have plenty of setups in multiple organisations where even within the org only the administrative settings of the server are locked down and everyone else is free to do whatever they need. Lots of teams just use it as a kanban board, while others setup a state machine-based funnel to process user/business input into usable tickets.
JIRA in its default configuration essentially lets you create anything, anywhere in any state. Anything beyond that is just bad product configuration. Now, there are plenty of products out there that suck no matter how you configure it (looking at you, ServiceNow).
Especially the comments about "I would rather use trello" seem extremely uninformed as you pretty much *are* trello when you just stick to one kanban board and one project.
It amazes me how much hate Jira gets compared to ServiceNow. My last two roles have been heavy on the ServiceNow, and I'd take a fresh breath of Jira any time.
My guess is it's because Jira actively targets SMB, while ServiceNow is almost strictly enterprise, and folks in enterprise have already resigned to their fate.
I think the comparison mostly stems from the legacy enterprise where badly configured tools are pushed top-down and workers are told to 'deal with it'. Either you'll be a developer mostly using JIRA or a non-developer mostly using ServiceNow, and if you're really unlucky in such an organisation you'll be using both.
Having a Service Desk that actually provides usable and composable tooling is a benefit for all. Having a random contractor "implement" ServiceNow because Gartner said so is a pain for all. This is of course a bit of opposing extremes, but the same applies to JIRA and AD and pretty much anything else. Hard-pushed bad implementation will ruin your workday.
Teams that are capable and allowed to self-steer and deviate from company policy if they come up with a good enough reason seems to be the sweet spot of attainable & realistic.
I have only ever seen servicenow used for… well, service requests. Reset my password, grant access, create this resource. Always administration, never product development.
I've seen it used for way more than that. Their sales (and customer support) people will gladly tell you it can, or soon will, do everything you may want it to do.
ServiceNow is just about the most user hostile software I know. I know that any request I make that ends up in SN will take 2-4 times as long and i will never be sure that anything is happening or that they person on the other actually knows what I want.
The answer is "way more than is sensible, even factoring in how absurd pricing on crap like this has gotten."
We dropped SN a couple years back over this. They were charging us about 6-7x what we pay for Jira, and we still use the on-site enterprise version of Jira.
“Let’s have a kickoff, invite everyone in the company who may be interested, and white board out all the possible use cases. We have an exciting new pricing model that will greatly simplify pricing on your existing business. But I can’t tell you that price until after the kickoff.”
We have a few of those around as well. While they work fine, I don't really get why anyone would want to self-host JIRA or any COTS product like that anymore. Most instances now seem to be just a case of "our hosting company is fully responsible for it and it's pretty cheap and reliable" and until it starts failing or falling behind the cloud offering it'll probably stay like that.
Usually, if it isn't better from a staff-perspective or better for the customer, self-hosting or self-building is less likely to be the answer these days.
Self hosting is sometimes easier to do than to argue with data governance about putting the information out a system that is offprem. The additional precautions for HIPAA or PII data that may show up in the comments or attachments can problematic. There are far too many users of all stripes that copy and paste data that they have access to without doing a check on it to see if it really does belong there (and if it does belong in the issue, then applying appropriate permissions to the object).
And how long is this going to last before someone further up decides that Jira needs to be unified for reporting purposes?
Eventually somebody with the organization obsession is going to get hired and put somewhere important and their goal is going to be making something complicated and unified and dissent will be "discouraged".
“Data needs to be unified for my executive use case” sounds like an org problem not a JIRA one. I’ve encountered it at companies that didn’t use JIRA at all
Depends on where you work I guess. In reality, reporting really has nothing to do with SWE state tracking. You can also just write a report in a letter and mail it to the board. It's not like they are going to log in to JIRA or even have an account or SSO-allowed credentials since they don't need to be there.
On the other hand, like almost copy-pasted here, if a top-down 'unification make it worse for everyone' effort is started, no vendor or tool is going to stop that and your work will get worse.
Spot on. One of the reasons we created Atlas (new product) was precisely this: help stakeholders and dependent teams focus on common language between teams over this misconception that task-level reporting is how they help understand the true state of work. Disclaimer: I work for Atlassian on Atlas, and I didn’t think I could ever get so passionate about soling this problem.
> JIRA in its default configuration essentially lets you create anything, anywhere in any state. Anything beyond that is just bad product configuration.
That's kind of the point, JIRA has been made into monstrosity at many organizations because the "create anything" mindset.
How does that make it a monstrosity? Unless we're talking about things that are shared across multiple teams, does it really matter how people use it? Nobody is going to care what someone else does in JIRA when they aren't touching that part anyway. Even with 1000 differently configured projects, your 1 or 2 projects you actually work with and configure are the only ones that matter.
Because it attracts somebody 4 layers up to tell somebody 3 layers up to come up with a common Jira platform for everybody and then you don't control how your project is run and then Jira becomes the enemy, a faceless micromanager driving your work life that has strong opinions on how you do everything, a dozen steps that need to be done "right" or you get your half a dozen managers asking if you read the memo about TPS reports, er, Jira tickets.
> it attracts somebody 4 layers up to tell somebody 3 layers up to come up with a common
with pretty much everything, including a spreadsheet or a plain text file.
Conflating bad business practises with tool configuration or products in general doesn't help anyone. If a business is very stiff and scared of its employees, they will try out all sorts of useless control methods hoping it will somehow make some metric 'better'. You can do that with Trello too. Doesn't make Trello a bad product, and it doesn't make JIRA a bad product.
At the same time, pretending a larger organisation with many teams can function without any form of state tracking is a nice dream but not a reality either, so it's not like you can do without anything at all. But like reposted a bunch of times, how you do it and who is responsible for it is pretty important.
The point is that there are tools that enable and encourage bad behavior. The kinds of organizational toxicity simply aren’t possible with some tools, sure an ambitious executive could try but the attempt would fail very quickly. Such attempts to do the broken overburdened nonsense that frequently comes with Jira don’t fail, they are enabled and encouraged. What is technically possible and what is likely are two very distant things.
"The tool can't do it" is an excuse. Excuses aren't tolerated. Now, make it happen.
Tools can't prevent bad management because bad managers don't care about tools. They care about getting what they want, and if the tool doesn't enable it, that's their underlings' problem, not theirs. Jira doesn't stand in their way because nothing stands in their way.
That's precisely why Jira sucks: Because it doesn't stand in their way. And why you want simpler software, which by not being able to bend to their misguided will, does stand in their way.
JIRA really doesn't encourage anything in any direction except writing down what you are up to in a reasonably friendly way. Anything beyond that is up to the implementors, and there is nothing in the world that can prevent bad top-down behaviour within a company.
> JIRA really doesn't encourage anything in any direction
Given the amount of effort you devoted to replying to multiple posts, it feels disingenuous when you make an obvious and inaccurate statement as fact.
There is very little dependency graph organization (eg subtasks), which isn't reflected in most of the UI anyway as JIRA does push toward treating all tickets as a flat set. Work is a practical hierarchy of concerns and JIRA never made much progress away from a checklist (same as ASANA, Rike, etc).
"Implementors". Anything that needs to be "implemented" is either a) not finished, b) too big and complex, or c) both.
Dunno for sure how much less code Jira has compared to, say, MS Excel or Adobe Acrobat, but I could imagine it might be up to an order of magnitude. But you don't have to "implement" those; you just install them.
But no, that's missing the point: That's what makes it an equally stupid "Enterprise product". Excel, OTOH, is arguably more essential to more corporations, and yet you don't see big international consultancies snap up contracts for six-year-long "Excel Implementation" projects with Fortune 500 corporations. You do see that for SAP, Oracle Business Suite (or whatever it's called nowadays), etc. They're products that you don't just install and use; they need to be "implemented". JIRA is more like that.
Or, IOW: I wasn't comparing, but contrasting. (Which, OK, is also a kind of comparison. But for this kind, it's Excel that is the better example than Teams.)
We're just talking past each other, I'm saying Jira is bad because "it's a foot gun, and bad people keep shooting me in the foot" and you're saying "they shot you in the foot because they are bad". We are both right, technically, but I don't like working with foot-guns for this reason.
It seems the pro-Jira comments here are basically, "It's fine if your organization isn't a mess and you don't abuse it."
That's the problem with any tool, framework, language, etc where the defenders main argument is, "It's great as long as you don't abuse it." or to put the former bluntly "It's not the tool, it's your organization." Over and over and over again, if an organization is allowed to abuse and misuse something, it eventually will.
Good tooling has opinions and will give you guardrails to not hang yourself.
Exactly, it's the same with C++. You can do great stuff with it as long as every single developer on the project is extremely disciplined and knowledgeable about its pitfalls.
As organizations and projects grow you or someone else will at some point hire incompetent people that mess up this delicate balance.
Jira is highly flexible and customizable, almost to a fault. One Jira can look and operate almost totally different to another with enough customization. If Jira feels inflexible and bureaucratic to you, I'd argue that's only a reflection of how your Jira admins operate or the rules they are forced to implement.
Customizable, absolutely to a fault. It is the infinite customizability of a tool targeted towards middle management which is why Jira can go to hell.
It is indeed possible to not be in Jira hell, but inflation of complexity is inevitable and almost entirely irreversible. It encourages and accelerates the path towards bureaucratic hell. Any avoidance of this is a temporary aberration.
> Jira doesn't just reflect, it drives convoluted unhelpful bureaucracy.
I though so too, but now I no longer believe that's the case. This is because of two reasons: one questions the statement itself - and the other one questions whether the statement correctly identifies the organizational issue.
Firstly, almost every tool I ever used for project organization has grown to similar degree of complexity. All _software_ employed was strongly incentivized to implement new mechanisms of automation and regulation - thus right now I would struggle to name a non-defunct and non-single-user tool that doesn't have the issue. And certainly no tool that that I would call "established" - an arbitrary designation, to be sure, but that largely reflects that the complexity almost _defines_ establishment for a project management tool.
Secondly, because I think the issue isn't, truly, the _bureaucracy_. Right now I believe it's the _technocracy_. It's the belief that every process has to be codified into software, and enforced in a manner that would make exceptions impossible without a pull request. This leads to
- increase in complexity (because corner cases that would be easily solved with a quick email exchange now require weird workarounds - and if they are too common, actual change to the software)
- reduction in real organizational flexibility (any special case is now discouraged on a technical level).
Worst part is, it's very hard to sell a shift away from this. Technocratic adherence to software-enforced processes became nearly synonymous to "accountability." In itself that's frustrating to me - I believe this serves to paint organizational failures as forces of nature, effectively reducing accountability. But, so far, I have failed to effectively communicate it to most people - with exception of the very few who, themselves, have a considerable interest in social dynamics, one that goes beyond the professional interest expected of a manager. And to those, those are generally truisms - I'm under no impression I'm particularly original here.
---
Aaaanyway, I went back to liking Jira - because, under all the cruft, there's still (or at least there still was) the basic bug tracker software that's almost like Bugzilla, but slightly less painful. And I like bug trackers, as long as they're used to track bugs - not manage projects. Projects are managed by people, and these days I believe that the reason all this software, as complex as it is, keeps failing to accurately communicate the project state, is because you would need the software to be a person.
Lighten up Francis. Jira is simply a tool. if you care that much, apply to be on the team at your company that defines the workflow rules and strip away what isn't needed.
It's not a neutral tool. Jira makes micromanagement easy and trusting people hard; you can use it for good, but you're working against the grain of it the whole time. Everything is default deny (issues can only go through approved transitions, by default regular users can't change the available transitions), the default issue forms have way too many mandatory fields, and a bunch of reports that only micromanagers want or need are front and center in the UI.
If you sign up to Jira today and start a new project, you'll get the options of a simple workflow with a minimum of fields. The beginning statuses are basically "to do", "in progress", and "done". There's a fair amount of trust in those steps, IMO.
> by default regular users can't change the available transitions
I can't imagine allowing this. This would be a recipe for chaos. The transitions are supposed to indicate agreed-and-defined steps that work goes through. They're supposed to reflect your team/org process, to the granularity that you want to capture it in Jira. Letting anyone edit them ad-hoc is akin to saying there is no process at all for doing work. How would anyone be able to interpret the state of work if everyone has their own ad-hoc process that they can change on the fly?
If that's okay on a team then that team probably shouldn't use Jira. I also would not want to be the team-lead, or anyone else trying to figure out what's going on or keep track of work!
> The transitions are supposed to indicate agreed-and-defined steps that work goes through. They're supposed to reflect your team/org process, to the granularity that you want to capture it in Jira. Letting anyone edit them ad-hoc is akin to saying there is no process at all for doing work. How would anyone be able to interpret the state of work if everyone has their own ad-hoc process that they can change on the fly?
Everywhere I've worked the states have been the steps, the transitions have just been there for Jira's own bookkeeping. And in the real world it's always possible to move a piece of work to any other step in your workflow - things like "the designer's realised he messed up the wireframes, put it back to design even though it was currently in code review" happen all the time. I don't think that's the same as not having any process.
In the Jira way of doing things you can't do that if that transition doesn't exist, and you probably don't have the required permissions to add that transition (if you can even figure out what they are). Couple that with Jira's terrible performance and I've been in more than one company where you could accidentally drag and drop a ticket to the wrong column (because Jira decides to finish loading at the wrong time) at which point it's permanently fucked up and your only option is to copy and paste the data (one field at a time, natuarlly) into a new ticket.
I realize company-wide planning is extremely hard, especially when there are many inter-dependencies that can block entire departments if a single deadline slips. But in my experience, the only thing that Jira brings to the table is the ability to document, in a centralized place, the pieces of work that need to be done, and what stage they are currently in. In my field, anything software related is really hard to estimate accurately, which makes the whole aggregate estimation in Jira not only worthless, but actively harmful because management will treat it as truth. We could replace Jira with a big whiteboard of TODOs and we'd likely get things done faster, and with higher quality. My favorite excerpt from the site:
> Jira is not completely useless: it gives people who usually add negative value
to the project a way to appear busy and productive, with associated rewards and promotion opportunities.
I view Jira as the embodiment of the misguided software engineering practice of trying to generalize and abstract too high level of a task of something like "project management" and distill it down into one tool.
While the Golden perfect abstraction handed down for the heavens by the gods is what you seek, it ultimately passes down complexity to end users through its generic approach. You need to create opinions within the generic world and then your team needs to understand Jira's abstraction combined with the opinion your company builds around it that's probably not documented.
The end result is unless you're running a large project that really requires the functionality possible in Jira where creating the overhead or overloading something simpler isn't practical, then you're probably better off using something simpler and more opinionated--a nice simple solid framework to keep everyone on track.
Almost none of that is true depending on which version of Jira we are talking about and what type of project you have chosen.
I'm in the Jira is actually pretty good camp. I've administered Jira instances from the ground up, including installation, integrating it with directory services, customizing workflows or just as a user in large and small organizations.
The defaults even way back when actually made quite a bit of sense. The default workflow for many project types were very workable. Some transitions make more sense than others. It was also quite tedious to create transitions from "all other states" to some state. So admins were incentivized to only allow transitions that immediately made sense to them and not bother with the others. From the end user perspective this obviously looks like draconian overlordship. While in reality in many cases its just too tedious. Atlassian has heard user complaints though and an "all states can transition here" option is available since some time ago and the default workflow for some types of projects are basically just a few workflow states that all have this transition as the only possible one. Basically transition from any state to any other state. No transition screens. That's pretty open.
If your organization chooses to instead use this very very configurable tool to lock things down you can't blame Jira. Locked down workflows and transitions, restructured editability etc do have their place in many valid use cases. A simple one being as a customer facing tool where you need to enforce certain things directly because your customer is not first going to learn your conventions and then self apply these.
The same goes for mandatory fields. The only mandatory field you have to choose yourself really is the issue summary. Everything else if mandatory by default has default values. I have used many a Jira instance where Priority (a default mandatory field that also has a default value though) was all but ignored by everyone even if it was still on screen.
Can you elaborate on the reports that only micromanagers would ever use? I agree that some of them can be used by micromanagers as can a lot of Jira functionality. There are many that can also be very useful directly in the hands of teams.
Team managed projects are awesome because sharing Jira admin rights in a large org was hard. Because things are so configurable a good set of naming rules were essential. It was usually easier to set up individual instances for projects instead of having a shared instance for large orgs. And if you centralize administration too much then changes grind to a halt. I have shared admin right with many others successfully though where these standards were adhered to by everyone and changes to work flows, issue and custom field definitions and such were easy to get through. Just required discipline.
> The defaults even way back when actually made quite a bit of sense. The default workflow for many project types were very workable.
That's probably where the wide-spread (and arguably correct) impression that it has become worse comes from: To begin with, people just installed and used it as-is, but by now corporate bureaucracies have had time to "implement" it -- i.e. set it up -- to mirror their organisation's bureaucratic structure and processes.
And yes, that impression is correct; it is Jira's fault: If it didn't have that customisability, they couldn't (ab)use it that way.
> If your organization chooses to instead use this very very configurable tool to lock things down you can't blame Jira.
Of course you can: If it didn't offer the possibility to set up those bureaucratic locks, they wouldn't be set up.
I can tell you that a lot of other tools before Jira that I have had to use were really quite good at mirroring that structure in a much worse way ;) Most of those tools from my experience were not usable in a good way.
You and other people are obviously entitled to the opinion that Jira made it worse.
In my book, that's like saying it's the Swiss Army knife's fault that someone was killed with it.
"My opinion is that Jira reflects the organisation that manages it."
Came here to say EXACTLY this. I've used Jira across 3 companies, and in the first 2, I always felt like folks complaining about Jira were just being picky developers wanting the sun, moon and the stars, because Jira worked perfectly fine for me and my team (in fact, it was the backbone of our process).
Then in the third org, I felt like I was hit with a brick wall of every single issue folks complaining about jira point out. Needless workflows, Middle Managers wanting to "control" how stories/epics get closed, multiple levels of convoluted manual configurations, automated processes creating Jiras that for trivial non-issues which clogged notifications and team backlogs and brought jira to a crawl etc. Heck, at one point, the mess got so bad, that the company considered hiring a third party to "fix" our Jira workflows. And note that this was a <100 person startup!
On introspecting, I completely felt that in the first 2 companies, the organization was structured around "getting stuff done" and "keeping stuff as simple as possible, but no simpler" and that naturally flowed into how Jira was set up as well, while in the latter, the focus was entirely on top-down "process", and that showed in the Jira setup as well.
Honestly, I now think I can say a lot about a company's engineering/product culture just by spending 15 minutes on their Jira ;-)
The central problem with JIRA is that, once you've gotten beyond the overly customizable functionality and difficult-to-reason about permissions, and once you've managed to avoid organizations that go too far off of the deep-end and once you've finally found a happy simplicity in a kanban-ish board,
once you've done all of that, it is still unbelievably, unjustifiably, just incredibly and amazingly so very very goddamn slow.
There’s a screen in jira if you change multiple items with a progress bar. I looked once and the operation seems to happen instantly and the progress bar is just there because of some bad designers ego…
Yes, we switched to Jira from a piece of abandonware (simple php based bug tracker) several years ago. Jira is kinda slow sometimes, but not horrible. And yes, like you said, once you get it configured it works great.
Overall, we are very happy with Jira and it's worth the cost for the value it brings to the organization (still hurts the wallet, but it's at least justified).
...and then Atlassian comes along and rug-pulls on-prem Jira.
We only have ~80 users, so 1000-user-minimum data center isn't going to cut it for us. And there is an on-prem requirement, so no cloud option either (wouldn't want to anyway). And for that, I bitch. Fuck Atlassian and everything they do to appease their shareholders before the customers.
Yeah that's a bit rough. Though I think for most people the cloud solution is the way to go, though - even if it's an evil Saas-recurring-revenue play. I was close enough to a previous team that used to admin an on-prem Jira (~7 years ago) to know it wasn't just set-and-forget, and also that almost all the slowness users complained about was due to under-provisioned hardware.
Honestly I reckon half of Jira's reputation for slowness could have come from bad on-prem installs. The cloud version is not slow, and Atlassian does do work on performance
funny you should say that given a bunch of these rants on the article link sound very much like the cloud version in terms of amount of JS loaded and network requests.
Also no shortage of folks elsewhere in this discussion talking about cloud slowness.
We've had plenty of irritations with our on-prem, but slowness, not so much. And yeah, for us it's mostly about keeping the data internal.
This applies to all enterprise software. It’s also called Conway’s Law:
Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.
> It's faster, there are options for simpler configuration, and more stuff out-of-the-box (assuming you're on Cloud, but isn't everyone these days?).
My understanding is that the Cloud offering is the slower one, assuming you can dedicate a beefy server (but probably under $200/mo on hetzner or ovh for most businesses) to running your Atlassian stuff.
My opinion is that Jira reflects the organisation that manages it. It's basically a whole lot of customizable UI and permissions hanging off a user-defined state machine. You can set it up so that individual teams can fully administer their own projects, or you can go all the way in the other direction and have centralized, locked-down management where you beg some internal specialist Jira admin(s) to make your changes.
Also, in the last couple of years it's got a lot better. It's faster, there are options for simpler configuration, and more stuff out-of-the-box (assuming you're on Cloud, but isn't everyone these days?).
In detraction: configuring it can be a huge PITA. So many screens, concepts, and so much clicking. But when it's done it works, and I think most of the hassle is just inherent complexity from such a configurable tool (if you haven't Admined Jira: you can change almost anything).