Atlassian cripples’ Jira automation for all but enterprise customers
community.atlassian.comGitHub and GitLab workflows are much more convenient in my opinion. They were made with actual workers in mind: developers, QA, release managers, DevOps, etc. Jira, on the other hand, is purely manager's toy with all it's useless features that often stand in a way of daily routine. I never saw any developer who was happy about Jira.
> I never saw any developer who was happy about Jira.
We did a clean Jira setup from scratch as set up by developers for developers. It was fine.
It wasn’t until the company hired full time TPMs who made it unnecessarily complicated with an endless list of plugins and processes that it got to be miserable.
The real killer was the way they wanted us to use it: They declared that only TPMs could move tickets, and only in meetings. So instead of us moving our own work along we had to queue it up and wait for an hour long meeting where we waited our turn to tell the TPM which tickets needed to be moved, then sparred with him in debate for 5 minutes as he tried to debate the done-ness with us through a game of 20 questions.
Repeat those meetings 3X a week and I developed a visceral objection to Jira. Only later did I realize that what I hated most was actually the pomp and ceremony that came with Jira-toting TPMs.
Jira itself wasn’t too bad when we used it efficiently on our own. The modern versions are much faster than the sluggish experience of the days of old
It is one of the great tragedies that the Agile Manifesto - which is literally four sentences that fit on a cocktail napkin - got turned into thousands of pages of "standardized Agile", with the biggest abomination in the world being SAFe. I swear, SAFe was a prank, and when people took it seriously they decided to cash in on it.
That said, a good TPM is often worth more than a good engineer. Herding all the cats across multiple teams, projects, competing priorities, keeping track of stuff, holding and being held accountable. And part of a good TPM is to find the right way to work. Maybe it's Kanban. Maybe it's Scrum. Maybe it's Waterfall. Maybe it's a mixture of different methodologies, like waterboarding.
That was the whole point of "Individuals and interactions over processes and tools", finding the right way to work for your team. Jira has to deal with the fact that it's meant to be a tool that fits into any company, so it's generic/customizable, and I've seen too many teams go crazy on the customization, trying to model out a massively complicated process when the team really just needs Kanban with a few extra fields.
I don't hate Jira - I don't like it very much, but I acknowledge that a lot of Jira's issues boil down to mediocre PMs being in charge of it.
Having worked with a good TPM that can really make things happen was eye-opening - tools like Jira can work beautifully if they are setup properly.
>> Maybe it's a mixture of different methodologies, like waterboarding.
I'm going to be thinking a lot about this notion. Thanks for the choice wording.
Jira's UX is quite bad though, even when there's not much red tape from management on how to manage your tickets.
The response time for a "Create ticket" flow gets in the way, I like how snappy Trello feels, I can create a ticket in seconds with just shortcuts and a few keystrokes so it's pretty effortless to split a task in multiple tickets to be worked on. The clickety-clicky nature of Jira gets in the way for that, I need to click "Create", then select the "Project", then click on the modal's text box for writing the description, it doesn't support Markdown so I need to keep in mind (increasing the cognitive load) how Jira's formatting work. Then I need to click "Create" while checking the box "Create another" so I can keep the flow of adding more tickets.
Over time this workflow is fucking terrible, sometimes I avoid splitting some larger task into multiple tickets because I can't be bothered to go through this flow yet-again.
If Jira just simplified the way to create tickets, throwing them into an "Inbox" to be sorted later it'd improve the experience a lot, the way it's designed doesn't help to be fast with it and breaks my train of thought.
My workflow right now is to open a text editor, write down all the tickets I want to create, their descriptions, etc. and later I just copy-paste into Jira's UI when I have the energy to go through the whole song and dance of creating tickets.
It's death by a thousand cuts, the ergonomics of it is pretty bad.
I’ve come to a similar conclusion. I linen using JIRA to going to the DMV. Most seem to agree with the comparison.
Looking into moving over to GH issues or linear.
>Repeat those meetings 3X a week and I developed a visceral objection to Jira. Only later did I realize that what I hated most was actually the pomp and ceremony that came with Jira-toting TPMs
Jira's like guns: it can be used for good or evil. But given how bad the worst case can be, would you really want to leave a bunch of rifles lying around your company?
Guns: the only good outcome of a gun is it is never used, virtually all other uses of guns are differing flavors of tragedy
Perhaps people don't remember the days of bugzilla as a product, or various CA (computer associates) software. JIRA is bloated and probably inferior now, but it was a far superior option about 15 years ago.
Yeah it was once the cool kid in town.
Just recently I read a nice quote here on HN (paraphrasing):
Either you die young as a hero or you live long enough to become the villain
> virtually all other uses of guns are differing flavors of tragedy
Like the Olympic biathlon.
What happens more often, a biathlon, or a school shooting?
Women's division I'd say biathlon.
Not sure about men's though.
I still absolutely miss the really early iterations of JIRA. better than a bug tracking system but none of the complexity on top. we were still managing our projects as waterfall using Microsoft Project Planner but devs were doing all their work in Jira. we had complex workflows that were managed really well, approvals built in all sort of good stuff.
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).
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.
Funny anecdote - "Jira is still growing and I have personally talked to many developers who love it". There is an inherent bias in Hacker News on certain stories or perceptions getting amplified. This is primarily the silicon valley echo chamber.
I have been reading about how Jira is going to die for the last 10 years. It has not happened yet. And I don't foresee it happening in the near future - there are so many competitors in the graveyard: Asana, Monday, ClickUp, Product Board, Clubhouse, and Linear will be next.
Jira will not die , even if every last developer on the planet hate it , they are not the buyers . I have never seen a manager express negative feedback let alone hate it . As long as managers keep liking it over anything else , nothing will change .
There are no realistic peers to Jira for, developers or knowledge workers have to use the product , it only has to designed for the buyer , which atlassian does very well
Try out zenhub. It gets enough of the manager juice in there that they can feel comfortable with it, but sits happily in GitHub, atop GitHub issues and pull requests and all that
30+ years of experience developer here. I am happy with JIRA. It isn’t perfect but nothing is.
Meanwhile, a company I used to work at keeps on using self hosted MantisBT.
Its maintenance takes like 2 engineer days per year total, if that. Its initial setup with all the plugins ( of note are those for project management and release tracking) and integrations (e.g. git) took one engineer week if I remember correctly.
And it works just fine for 7 years now, to the point that the only advantage of Jira I see is a slightly fancier looking interface for the regular user. Whilst costing peanuts.
I even prefer the old school Mantis BT look and feel.
Mantis! Last time I used that system was in 2012 - also self-hosted by the company.
My impression of JIRA was always that it felt slow - at least compared to our Mantis instance. Mantis might not have such a ridiculous range of customizations, but does a small to mid-sized business ever use most of them?
Lots of discussion here of whether Jira is any good or not. Almost none about the actual contents of the article.
None at all about how the changes are bad for all but enterprise customers. It's not obvious to me - and it would be nice to have an explanation.
Atlassian has always been "enterprise-first" as far as I know. I can only assume that their free-tier which I've rarely encountered in the wild, isn't that successful in terms of conversion to the full-fat product or is costly in some way. I couldn't decide whether enterprise customers would be any worse off.
I've maintained for a while that the bug-tracking industry is overdue a "v2" or "v3" product (e.g. IRC -> MSM Messenger/Yahoo -> Slack-Discord).
I don't know which world you live in - it was never an enterprise first company. From the very beginning it catered to teams (not orgs) and refused to sell to the enterprise.
I worked at "megabank" back in the early 00s, and we were one of the first purchasers of Jira.
I think this is the section: "In today’s model, an automation rule that is configured to run in a single Jira project does not count toward the usage limit. In the new model, all automation rule types (i.e. single project, project type, multi-project, and global rules) will count towards the usage limit."
On September 18th Atlassian announced a new license model for Jira automation that severely limits automation for all but enterprise customers starting November 1st. Many customers will be forced to give up their automation or upgrade to expensive enterprise tiers. Since there is no enterprise tier for Jira Product Discovery customers using automation in this product don’t even have the option to pay more.
> Since there is no enterprise tier for Jira Product Discovery customers using automation in this product don’t even have the option to pay more.
This one is fascinating. I get paywalling features. I get removing features. But just turning them off is unusual.
Atlassian has been doing this for years, killing the server versions to force people into cloud and revenue, etc.
If you’re on their products I feel for you son, but if you’re starting out I’d avoid anything Atlassin infected.
To be "that guy", the submitted title is heavily editorialized
I am the ultimate smart tech man at my company.
Warned them about Jira.
Warned them about M$/Sharepoint/Power Automate.
Jira and New M$ services are at bait pricing. They will all be extortionary levels at some point.
Kind of amazes me people are paying for inferior closed off services, but I imagine the people making the purchasing decisions are more concerned about which concert or sports game the sales person is taking them to.
This is more or less my life as well.
The "finisher argument" that gets rolled out is "product lifetime costs". It goes like this.
Open Source Product A will always be your responsibility, which will take X hours off the team's time forever. Vendor Product B will be maintained from the vendor side, thus removing that wildcard of X. Ergo, over the "lifetime" of the product, B will have lower costs than A.
Since this argument has dollars in it, it always wins, and everyone makes smug faces.
I personally think it's almost completely ridiculous to evaluate software with anything called "lifetime costs", and honestly, it's getting pretty close to ridiculous to cite that metric for any complex system, physical or not. But that's just me[1].
I'd be interested to hear what the general readership's opinion is on whether or not the "Lifetime Costs" argument holds water, and why.
[1] In the software case, what's a "Product" "Lifetime"? Is that "the software in its current precise configuration", because then we're talking a lifetime of picoseconds. Or is Product defined so broadly that virtually any software of that class can be called "the Product", in which case you're stretching my credulity to say you're capable of supporting this notion of "Product" for N arbitrary period. I don't think you will make any money doing that. Either way . . when it comes to "lifetime costs" for physical complex systems, there's a supplementary argument, out of scope for this discussion, but still applicable in heavy industry.
Open Source project O will cost your team X hours of time to develop expertise in managing it.
Enterprise product E will cost your team X hours of time to develop expertise.
O requires install time. E either requires install time or integration time.
When O breaks, it is likely that the community has already seen this problem and can provide suggestions via docs, mailing list archives, discussion fora, blogs... Your team's expertise will increase. If your problem is interesting, the developers will likely get involved.
When E breaks, you will open a ticket. Within 24 hours, someone from the E company will try to diagnose your problem, going down a flowchart that they will not share with you. If your problem is in the FAQ or flowchart, it will get solved within a week, probably. If your problem is interesting, it may eventually be solved in a future release. Your team will spend less time working on it, but E will be broken for longer.
You will pay dollars to your team to support O, which will make them happier.
You will pay dollars to the E company to support E, which will make them happier.
E will invite your execs to dinner at the E conference.
O will never invite anyone to anything.
This is the secret.
E will also conduct award ceremonies and invite the suits - "Best Practices Journey Award 2023".
O will have a virtual hackathon broadcast on their self-hosted Jitsi.
You forgot the cost of Y hours your developers could have spent on A.
This is the actual, non-cynical driver for many of these decisions. An exec is looking at devoting developer time to building or curating software that isn't part of the core competency of the business, and balancing it against staffing product development or IT aimed at the business's specialization.
To make avoidance of E palatable, you have to show that use of O will not only cost significantly less that E, but that using it will also make up for the lost time that you would have spent building A.
I say this as someone who constantly has to justify why we don't just grab some SaaS offering off the shelf and groom it * cough * um... integrate it, rather than continuing investment in the purpose-built "commodity" my team runs.
I actually agree with the "lifetime" argument. The real fallacy is here:
> Vendor Product B will be maintained from the vendor side, thus removing that wildcard of X.
Product B also has a lifetime cost as you'll be paying monthly for the subscription.
Also no product is maintenance free, even as you pay for it. Products evolve, you also do, next months JIRA could break some of a company's use cases and they'll have to deal with it. The vendor might be helpful and guide thsm through the process, but that's still work.
A good example of that is Microsoft's enterprise offering: it's a paid product and you still need a department to manage it day to day.
I dig it. And yeah, B has license costs, but those often go to a different cost center so they're invisible[1] . . and as we all know invisible things don't exist.
We'll agree to disagree that "lifetimes" are a real thing in software - I actually think this is a pretty fluid thing - but I'm going to extend your case here to illustrate how "lifetime" interacts with incomputable costs. We have the known license costs, as stated above, but then added to that we also have this unknown cost that represents "how much time my team needs to spend maintaining the vendor product". That cost is unquantifiable but it's going to go up the less tightly-defined the product is[2], and, as stated, there is an inverse relationship between "lifetime" and "tightly defined".
So you're in a situation where the lifetime is either very short, or the vendor costs are high. But you never know "how much my people will need to do at the very base level of vendor support" so the multiplier can take it way outside of the range of "acceptable" very, very rapidly, with just a small increase in scope/lifetime. You end up paying out more for the vendor support than you're making from the Product, thus operating the whole shebang at a loss.
I think this is much more of a problem when in a domain that's not commodified, or even worse, something that's extremely niche. I'm thinking of SGML and FOSI publishing systems, specifically, but it could go for anything way out on the fringes, like weirdo material-assembly-or-org-specific CAD functions. I'm going to go out on a limb here and say if your business depends on niche, you're really way, way, way better off in-housing that, then interfacing it with the commodified functions that can run off the vendor. There's no ceiling on how high the vendor costs can go with niche stuff.
[1] Please don't get me started on cost centers.
[2] For a given cost, Product grows in scope, less profitable for the vendor to staff for supporting it, support goes down.
But what if that vendor product B got crippled (like recently Unity and today JIRA) for most of features that people deemed essential, or even vanished? People who is less fortunate has to switch to more cost-effective solutions (it may include F(L)OSS ones).
A slightly less cynical take is that "nobody got fired for choosing Jira/Microsoft/IBM". It's easier to justify choosing a market leader, even if things go badly later, than going against the grain.
In my experience at mid-sized companies the decision is usually made by the development teams themselves who have a choice along a spectrum between a proprietary SAAS solution that may end up costing the company unpredictable amounts of money in the future on one end and a self-hosted open source solution that we have to trust the IT/devops folks to maintain competently on the other.
Also in my experience, the companies that were the most cost sensitive with regard to paying for dev tooling were also the ones with the weakest IT/devops support so you either end up with two good options or two bad options.
The cold hard math that engineers never want to do is the one involving their own salary.
On levels.fyi devops is median $150k in the US, and at that price it means they cost the company a lot more including benefits, taxes, etc.
If a "crappy" tool costs $10k/mo for the team and doesn't require much or any devops time to setup and maintain, it's likely cheaper than the $0/mo opensource but requires part or full time management option.
No one ever wants to budget their own cost into the equation!
What’s left out is accounting of the time the paid tool wastes. Ten seconds here, a minute there, two seconds another place. If the open source solution is in fact the more productive tool (nb it might not be) then $20,000 in dev time to babysit open source might be cheaper than the $10,000 paid tool—because that tool is wasting more than $10,000 in productivity, it’s just harder to see.
The buyer often doesn't use the product so he has no sense of the value it provides, or the pain of using substandard tools. Unless it's his own company he might not care that much either.
> If a "crappy" tool costs $10k/mo for the team and doesn't require much or any devops time to setup and maintain, it's likely cheaper than the $0/mo opensource but requires part or full time management option.
This is a total fantasy. There is no reason to expect the crappy enterprise tool that costs money will save time relative to the open source tool. In my experience enterprise tools takes more time and average and cost money. This line of reasoning (frequently pushed by dishonest sales people) is seductive because it tricks you into ignore the time cost of dealing with enterprise, not because it is correct.
I think you must be in some terrible giant corporate entity where everything sucks all the time.
I bet you that what I told you about this cost/benefit is being done in every startup that YCombinator funds. I bet you they are all choosing product over staff, because their engineering staff is already their ~largest expense. Their engineers might even cost more than the rest of the company combined including executives.
How many companies are choosing SaaS/PaaS/alltheS so their lean team of engineers can scale to millions, instead of hiring a whole team to manage AWS and docker or whatever ops strategy they have.
You might think it's a total fantasy and in the places you work it may be, but I've been in countless meetings with countless executives where the Google Sheet is busted out featuring engineering cost and tool cost and where cost/benefit is aggressively decided.
Spoiler: it's almost always cheaper to use the tool
> I've been in countless meetings with countless executives where the Google Sheet is busted out featuring engineering cost and tool cost and where cost/benefit is aggressively decided.
That is the problem though. It isn't the engineering cost vs the tool cost. It is the engineering cost vs the tool cost PLUS the engineering cost of dealing with the tool once you buy it. Everything you have said so far leads me to believe you are missing this aspect of the cost of buying the tool.
You are right that there is a time and a place for buying over DIY, but in order to make those decisions reliably you need to know how much effort is going to go into dealing with the tool once you buy it. This isn't something you can figure out using Google sheets, because you have to actually evaluate the tool and get a sense of how dangerous the foot guns are.
You're probably right about scaling though. That sounds like an area where the ROI of paying someone else to do it is pretty good.
The same argument applies to the users of the software though, and seeing that played out is even more rare.
If I can run a $0 tool that saves 100 people half an hour a month each because the workflow is better, that's $4k in the "pro" column right there. I should be able to justify spending a day a week on just that one product.
It's not about the cost, it's about the value, unless the products are perfect substitutes, like nuts and bolts. Software products will always differentiate themselves so you can't fairly compare them just on price.
I think you are correct precisely because this is how rentier economics seems to work out in every sector - just look at the housing market. Any captive audience that gives up agency to a third party in exchange for a subscription is ultimately beholden to the whims of that third party. It's an inherently risky proposition.
The thing that drives me nuts about jira is its gated features and forced way of working. I should be able to turn on the initiative planning and work dashboard for a single project.
Case in point, I spent hours creating fancy new ticket tiers and guess what? They don't appear on the initiative planner because it goes outside what atlassian wants.
I've written this to them but they don't see the point in making an adaptable ticketing system. It is what it is
What would you recommend as Power Automate replacement?
Python.
I'm pretty uncompromising about that.
Maybe autohotkey in addition.
What do you want to do? There is: Zapier Make IFTTT Integrately Etc etc
A ton of automation tools out there.
I was a big proponent of Jira over all other PM systems because of its functionality but now? Gitlab is better, and isn't enshittifying as quickly as the rest.
I've been hosting Taiga for a small team and it's been a pleasure to work with. Can't tell how it'll work for a 100 developer team with multiple product managers, scrum masters etc, I'm hoping someone else here has an idea. But for a small team of 25-30 people everything's smooth.
Website: https://taiga.io/
Docker: https://github.com/kaleidos-ventures/taiga-docker
Docs: https://docs.taiga.io/
We're using azure dev ops and recently started leveraging their Pm tool for our requirements management.
So far, I've been impressed. It took a little time to figure out how to operate within their paradigm. Once we tackled that, I don't see is going to another solution.
For better or worse, 365 is a pretty decent suite. Integration across their stack is a little schizo at times but it works well enough.
The only Achilles heel right now is ms project. They're planning on EoL it but in true Microsoft fashion are cagey when they plan on doing it and the replacement is lack luster at best. We're switching to Wrike instead which has so far been what we want.
Some people in my org like to say "MS Planner is the kanban tool of choice" and... just... no. That's the big problem when you have an IT org that wants to buy heavily into the 365 ecosystem, you end up having to fight off utterly boneheaded migration projects.
While Jira and everything else by Atlassian has and will always be garbage, it looks way better than Redmine at least.
Nah. It works really good. Not garbage at all.
I couldn't agree less. It costs a fucking ton and does not enable us to find information well, document stuff properly, and don't get me started on the fucking opaque permission management.
Someone else is paying (megacorp)
Search is great
Confluence full text search is so bad that there are memes about it…
The search is great? I have to disagree on that as well.
You can make specific querirs with jql on jira and confluence just works like a google search.
I don't know what you are disagreeing about. I would not buy it myself due to pricing, but when I find it running in corporate land, it is great to use.
I never use the search because it's so bad, it never finds literal matches of a document title for me. I always have to navigate to the pages/star them in order to find stuff.
Redmine sucks; upgrades are painful unless you're very good with managing Rails. We are looking to switch to YouTrack.
Thanks for the data point! We tried Space but couldn't get used to it. Was in beta tho. I also didn't want to move away from GitHub back then and especially roam atm. So YouTrack sounds nice.
sourcetree?
That's the notable exception. I use that thing daily. I don't think it gets much love, but still good piece of software.
Just like code smells, there are workplace smells - practices that indicate a place is meh.
Use of atlassian Jira is one such smell.
My blacklist: - Jira - Confluence - Salesforce - Anything SAP, but especially HR products - MS Teams - MS Sharepoint
So, around 98%+ of companies?
Unfortunately yes
Teams is high up on the stink list - its steaming.
Interestingly Slack Workflows also introduces pricing. So it seems both companies are targeting charging for automations / charging for things which used to be free.
I don't use Jira but any bad faith move (as claimed) is a serious concern for users of other Atlassian products.
I've always been a champion of Trello and really don't want to be having to add cautionary notes about corporate sharks owning it, and functionality taken for granted being whipped away. Not cool.
Bad faith move? They gave ownership of my Bitbucket account to someone else and initially refused to even tell me what they did:
Smells like that someone else were given superuser...
Jira's APIs are bloated horrid nightmares and I hope this drives people away from actually leveraging them.
you can also use open-source automation tools like n8n or windmill.dev, or github and gitlab workflows as mentionned above.
Why would you use tools/olatforms that was clearly made for enterprise as non-enterprise. Plenty of free tools and platforms around. Github for an example has really good F2U workflows.