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
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.
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.
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?
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.
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.
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.
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
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.
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?
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.
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).
This one is fascinating. I get paywalling features. I get removing features. But just turning them off is unusual.
If you’re on their products I feel for you son, but if you’re starting out I’d avoid anything Atlassin infected.
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.
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.
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.
> 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.
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.
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!
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
I'm pretty uncompromising about that.
Maybe autohotkey in addition.
A ton of automation tools out there.
Website: https://taiga.io/
Docker: https://github.com/kaleidos-ventures/taiga-docker
Docs: https://docs.taiga.io/
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.
Use of atlassian Jira is one such smell.
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.
