Lol. At some companies, Jira workflows literally run the whole company. At my prev job, prod deployments were tightly linked to Jira.
Because that is where Jira primarily plays. In enterprise companies where it's rolled out across the organisation with tentacles firmly embedded into almost every process and system.
And whilst people continue to criticise Jira it continues to grow because in reality it competes with products like Rally not Asana. And there really isn't anything out there that can offer the same level of customisability and flexibility.
But in the meantime, it requires increasing discipline and regular revampings of internal processes across dev, product, market teams, and that's a lot of energy to burn to make it "work" across an org.
Even more when you have people that are for very strict and precise adherence to processes.
Whereas a less flexible, good enough system could help funnel the same energy towards something more productive than just internal compliance for the sake of it.
You simply can't force one way of working on larger companies even if that way is undisputedly the right way. Because a lot of people will need to sign off on which tool to purchase and each of them are special geniuses with their own special genius way of working.
I'm not opposing a single Jira methodology to a myriad of other ones (tools or processes).
I'm saying that Jira, without being constantly challenged for what it is[1] creates its own growing and tiring bureaucracy because companies (even large ones) cannot agree on a right way to work (but will add piles over piles of bureaucracy).
[1] exactly like what Agile methodologies, or some certifications are; where now it feels like almost no one remembers/knows how to organize teams _without_ resorting to anything that Agile-thinking has tainted.
It somehow relates to the fact that, in some companies, more energy and money is burnt over how to organize the work rather than doing the work itself. And it definitely shows.
Each team can have a different workflow with Jira
Jira works for non-software-development tasks as well
I've seen it used on companies having 4/5 levels of stories deep (think Initiatives/Epic/Stories/Subtasks/etc. Different companies split this different ways.
The plugins sound inconsequential but they are very useful (almost a must) in several occasions.
Is there a breakout of company size vs revenue for Jira? Because for the past 10 years I've worked only on smaller companies and they all, no exceptions, used Jira as well.
Most complaints I’ve heard about Jira boil down to the horrible processes people choose to implement in it.
Is like saying: "people can move overseas with minimal cost (other than shitloads of migration bureaucracy, frequent flying to meet family, put their entire furniture on top of a cargo ship)
Migrating out of JIRA is analogous to "trying to remove an invasive cancer".
MS Word, Facebook, WhatsApp, Visa, they all have network effects: every user you add makes your product more compelling, thus creating a virtuous circle. You need to buy their product because other people have their product.
Ok folks, let's use Jira!
Dept. Head A moves to Dept. D, hey everyone we are going to start using Jira.
Dept D. is being merged with Dept. E, Dept and new Dept. Head J is joining. E is using some open source Kanban solution based on CouchDB, hmm, let's go to Jira - other departments are also using it and then we can get rid of the CouchDB thing!
In point of fact where network effects of Jira is concerned, I have put some effort into learning JQL and setting up my own dashboards, so when you give me one of the competitors I get grouchy. I prefer Jira or Trello - also owned by Atlassian iirc?
The author points at monday.com: I used it a few years ago and it only has basic and useless integrations out of the box, even for a service like Gitlab. You either develop what you need youreslf of try to so something with Zapier.
ISO (the standards body) has started using it, I'm sure in part because large companies who contribute to standards were already using it. The committee that I am a member of switched from Bugzilla to it.
My experience tells me the complete opposite of this statement. Regardless of the the workflows, automation and whatnot there are tons and tons of IP hidden in tickets and over a long enough period references to them end up scattered all over your tools, commits, documents, wikis, IM, email, etc. etc.
When you move ticketing providers it's very likely you can't correctly migrate all of your existing data into the new system without breaking or losing some of it.
I detest trying to figure out why a certain code change was made, looking at the commit message only to find a reference to link to a dead ticket.
I'm not for or against Jira, but moving ticketing systems does not come at a "minimal cost" in my opinion and needs careful consideration and motivation.
Whilst I LOVE to crap on Jira, it has brought some magnitude of order and civility to the PMO's and at least created a familiar work environment for people.
God help me If I ever have to go back to word docs and sharepoint to manage project work.
Asana is great for SMBs but for larger developer teams it lacks a lot of features and integrations.
While Jira may have some unique features for developers, one of Asana’s selling points is how it allows non-homogenous teams (incl whole companies) to work together (and by themselves within individual teams) on a variety of different kinds of work (projects, processes, loose day to day tasks etc). And as for scale we have many customers with thousands of users (one tech customer of ours has 100,000+ users on Asana - most of them I’m sure would be product teams).
It always seems hard enough to get information out of JIRA using JIRA when I watch our PO in planning meetings.
Honestly, JIRA easily has one of the most sluggish and horrid developer experience so the bar wasn't too high to begin with. Visual Studio Online / Azure DevOps is far better than JIRA ecosystem imo.
Then it took about 36 hours to move the relevant code bases (a few dozen repositories, some of them 20+ years old) over to git, including the entire commit history. This was pretty slow. It could have probably be done faster but we figured, since we only do it once, we don't need to invest too much time. We scheduled it on Saturday morning so it would be done by Sunday afternoon and we had some time to test it before Monday hit the earliest timezones.
We had a backup plan in place in case it didn't work but it wasn't necessary.
The two repos were automatically synced for a while, to allow people who had started work on something on, say, Friday morning, to commit their changes to the old repos, rather than have to replay their work on the new ones. After that the old repos remained read-only, but we preserved them because, obviously, our issue tracker had twenty years' worth of references to old VCS revision numbers.
So it took about 6 weeks of indulgently part-time work (our infra team worked several hours a day on this, I worked... about an hour or so a week?) to plot this daring plan, and about two days to make it happen. The total amount of work disruption was likely non-zero but certainly small enough that most people didn't complain of anything other than having to learn git.
I can't say about Bamboo to CircleCI but, having gone through one of these, I can say with 100% confidence that if you start out right -- that is, your existing repository is not a mess of stale branches and weird merges -- and you don't go about moving fast and breaking things, moving from even an ancient revision control system to git is not really apocalyptic.
that's doing a lot of work in that sentence!
The first part does not realistically connect to the second part. Surely the author is aware that switching to new systems is actually quite expensive monetarily and operationally - definitely not “minimal”?
1) When the user wants to merge to master, at least one of the commit messages must reference a valid Jira ticket.
2) A Jira plugin was installed such that when tests were run in CI, a jira ticket was created to record the result (pass/fail). This somehow ticks a SOC compliance box
How out of touch can you be with the stickiness of enterprise SaaS, and still write financial commentary?