You can't easily dump Jira if you are using Jira, confluence, bitbucket, and whatever their CI/CD product is called (bamboo?)
It isn't the set of features that makes them sticky. It is the 10% of features the lead PM can't live without, and the slightly-overlapping-but-different 10% of features the team PM's can't live without, and the slightly-overlapping-but-different 10% of features the developers can't live without, and the roll-up report features the leadership team can't live without... There has been some research into this phenomena [1]. I'm not aware of a handy term for the phenomena, would surely appreciate someone pointing me to it, and the industry recognizing it and building for it, though.
Internally in my head I call it "multiplexing feature sets". Though I never say that aloud and just give the long-winded explanation if I have to bring it up in meetings.
> ...I don't see any reason why we should prefer Atlassian over Taiga, other than familiarity and inertia.
In large-organization dynamics, never underestimate the familiarity and inertia factors. I regularly see vendors screw this up so badly. Account management teams of even large organization vendors (so they should be taking action upon this, but apparently are not) regularly have no clue what kind of massive red flag it takes to push their decade(s)-entrenched product from "man we wish this could be better" to "you really need to fix this, or we need to start looking elsewhere".
How do you tell when a customer is just kvetching and presenting empty threats, or is laying it on the line to you? Easy: the customer is happy to share with you specific details of how the product shortcomings/defects are impacting line of business processes and the business impact (ask for this under the cover of learning what the critical business impact is so your support teams can devise the most appropriate tactical technical solution for immediate partial/total relief), and is eager for live working sessions with the customer's engineers.
And understand this: rarely will a customer reveal they have switched away until it is practically finished. They want to maintain what little interim support quality they have left, until they can step off. If your account management practices engage "all hands on deck" priority support when you get wind of a competitor in the wheelhouse, then you've lost before you even started. That's why the reveal is always a shock to vendors, and always a done deal when it is shared.
The time to understand that your product and product support consumption experience for a particular set of customer needs is horribly broken is when you notice a customer requesting product support leadership engagement more than 2-3 times in a year. If you aren't tracking those engagement touch points, then I guarantee you are losing license sales. They just don't show up in the sales metrics.
[1] https://www.sciencedirect.com/science/article/pii/S187770581...
If they get plagued by further security vulnerabilities then companies handling sensitive data will concede to migrate, but it won't be simple by any means.
If you believe changing people's habits is easier than ever, it's rather the opposite. Workers are less and less inclined to learn any other way . The alternative has to be order of magnitude better than what they are using, otherwise they will resist the change. The fact is atlassian provide good to great products overall.
Except that confluence and JIRA are both so slow that you'll still be there 2 minutes later waiting for it to load. Perhaps not everybody's experience is so bad? I don't understand how anyone could consider these products convenient given how ridiculously slow they were.
We used to do refinement meetings over video call (I guess everyone is these days) inputting into JIRA, and we'd literally spend 3/4's of the call waiting for JIRA to catch up with the words I'd typed. There's bad engineering, and then there's making writing a sentence text box lag with times measures in seconds.
Maybe I'm closer to their servers. Or you're using Safari.
Maybe I should measure it and post somewhere, I thought it was a well-known problem but maybe there’s something different about our setups.
Watching the network tab, all I see is a requests to `bayeux-sync1` endpoint that take 5 seconds or longer. There's always one of these requests hung when it enters this unresponsive mode. I suspect this is some part of the syncing system for multiple editors. Which, if true, makes it particularly hilarious to me that the entire point of this system would be to sync multiple edits, yet it won't let me keep editing while it's waiting...
Even taking the following into account?
>> Atlassian products are vast, integrated, and support all the crazy draconian processes that every insane project manager wants to implement.
Our support board has customized forms. These forms create tickets that can seamlessly be moved to our scrum board once they are vetted. We use JQL to manage a lot of the boards we use. We have custom workflows for different ticket types. We use the comprehensive access controls to grant partial access to users based on custom roles.
None of this rigidly enforces our workflows (aside form access control). Instead, it streamlines sharing information across departments.
When it comes to a company wiki system, Confluence is extremely hard to beat. (I’ve use so many wiki systems. Dokuwiki is my goto.)
All of these systems use a single user account. We use single sign-on, but we don’t have a large IT department to manage the dozens of services we access every day.
I think even that would be a good attack vector against Atlassian: For them, "integration" means adding links from one product to the other. If I were to pay for an integrated suite of tools, the least I would expect is that their bloody markup languages are consistent. But because Atlassian just buys random products and then doesn't seem to ever change a single thing about them, that's not going to happen.
People are like”use the shiny thing” forgetting the existing thing has, you know, stuff I actually use.
As much as I love to hate Atlassian, I feel like complaining about Atlassian is like techies complaining about management in general. Every single anecdote is both terrible and true, but it's not quite as easy as it seems to do it better.