I always wonder how much of this sort of thing is disdain for the specific tool vs. disdain for what working in a mid-to-large org. is like and the overhead it usually brings with it.
I work in a mid-to-large org. The more agile part use tools like jira and slack. The older part (established in the 1920s) use Remedy and Teams.
Jira is brilliant. It is team-led. Different teams have different approaches, some love all the features like components, versions, issue types, assignee, kanban boards, scrumms, reports etc etc. Others like my team use it with subject/description/comments. You make the tool fit what the team needs.
Same with slack, you can create and destroy channels around your team -- anyone can create any channel at any point it makes sense -- problem at 3AM, spin up a channel to discuss it, job done. You can integrate and add plugins nice and easy.
Remedy and Teams are led top down. They're designed to be organised, not organic. They're not built for the teams doing the work, but for the people wanting reporting. It's more about monthly KPIs than actually improving performance.
I have no doubt you can use Jira in a "KPI led" way. I do doubt you can use Remedy in a responsible way, but even if you can, it relies on the culture of those selling the tools.
Sadly I fear jira and slack will be next -- they already took Zoom and gave us teams instead, after all we "already pay for teams with office" (which aside from cloud-based email, I, and my teammates, never use).
Never has an anti-trust move been so obvious or damaging.
My feeling is... developers hate Jira, managers love Jira. And that is expected. The tendency is for things loved by managers to be hated by developers, such as meetings, metrics, etc.
An example of a very misused metric: In one of my jobs, managers started using Scrum Poker results as a productivity measure. “My team scored 100 points in the last sprint.” Imagine the chaos this generated. Quickly teams began to hate the Scrum poker.
Jira is probably just a scapegoat in corporate theater, something needs to be to blame. Jira is a good culprit.
> The tendency is for things loved by managers to be hated by developers, such as meetings, metrics, etc.
There's an unfortunate tendency for some people to scoff at the immutable fact that to write software, you have to talk to other human beings. And that if a company is paying you good money to do it, they are going to want to know when it will be done and what ROI they are getting on your salary.
Sure, there are stupid meetings and stupid metrics. But to lump "meetings" and "metrics" into a "hated" category is the mark of an immature dev who doesn't understand why he/she has a job and a salary in the first place.
It’s why I just can’t take some dev communities seriously. Too many immature / inexperienced people will talk eachother into thinking that their “I should just be able to sit here and code!” mentality is justified or even viable. Who the hell else gets to work like that? The utter hubris.
I work like that, but I love occasional meetings to catch up with peers. My immediate team of 3 people has a twice-weekly "standup" meeting, and communicate through the rest of the week in a slack channel. I have a weekly catchup with another team and a monthly with a couple more, and once every 3 months a large pan-org community get together in person, typically with a beer and curry.
Of course there are terrible meetings too. I currently have a PM who had 5 meetings with me a week on two minor projects. I don't go to those meetings, I just update the jira when there's an update. I need to do that as I am working on 40 things at a time and I don't have the mental capacity to remember how many plates I'm spinning. That's far more efficient, it's asynchronous, easy to keep on top of.
I see some colleagues struggling to get anything done because they are in meetings 6 hours a day, they go from one meeting to another without even a pause for a break. In those meetings they then try to half-listen and send emails about other subjects. They don't need to be in those meetings.
It sounds like you don't work like that, you talk to other humans at occasional meetings. I do mostly "just sit down and code" and it's a problem. Your situation sounds healthy and productive to me, I want to be more like that.
I talk to other humans at productive meetings - about 2-3 hours a week on average. Those that need updates don't need my time -- they're stored in the jiras. Crucially that information is still available months and years later.
If I didn't communicate, how else would I know where the problems are, or what other people are working on so I don't duplicate effort.
90% of my week is not in meetings though, and about 0% of my week is in business metrics (plenty of metrics on things like availability from monitoring systems, but nothing out of jira, because what's the point in trying to record metrics which nobody cares about)
> But to lump "meetings" and "metrics" into a "hated" category is the mark of an immature dev
To me, these things are normal occurrences in organizational theater. I ignore that. But after sitting in a few 12-hour meetings, participating in some metrics-based programming (MBP) and filling out 100 fields in a deployment request tool, I UNDERSTAND if someone hates this kind of thing, is not only 'immaturity'.
And I'm not try to change anything, my experience is that if we can convince those in charge to stop having unnecessary meetings or using metrics incorrectly, something worse will replace those things, like no meetings, but super micromanagement. ... because the nature of the organization that does these things is to continue doing them, in other ways.
Understanding that stupid/pointless/badly run meetings and toxic cultures exist is not the same thing as immaturely assuming all meetings are automatically time-wasters or that all corporate cultures must be toxic.
Exactly. Also developers often say they want less meetings so they can do more work, or something akin to that. But meetings _are_ work. And where I've worked there was always room to present feedback is a meeting felt unnecessary.
I'm a developer, and while I don't love it, I certainly don't hate it, and I don't see it worse than any other task-tracking tool. I haven't used trello or asana in a hot minute, but they were way worse in terms of UI and UX.
I'm not totally sold on the whole points poker process though, but that could be a criticism of agile as a whole.
> I'm not totally sold on the whole points poker process though, but that could be a criticism of agile as a whole.
My understanding of agile is give your developers the tools they want, the information they want, and the ability and incentive to communicate widely, quickly, and frequently however they want, and get out of the way. You have to devolve responsibility and accountability for meeting business goals down to the team level though, and that team has to act as one.
None of that has anything to do with "points poker process", or any process. Obviously everyone has a process, even solo developers working on their own hobby, but that process is "what works best".
"Agile as a whole" does not require planning poker, or story points, or burndown charts, or Fibonacci estimates, or Kanban boards, or any of that. Neither does Scrum. Google "Agile Manifesto" and "2020 Scrum Guide."
If it isn't in the 4 values and 12 principles, it's not required in Agile. If it isn't in the guide, it isn't required in Scrum.
Planning poker, story points, etc. are not an intrinsic part of agile (or even Scrum, from what I understand). Honestly, I'd not use them at all because they're not worth the time investment.
Yes, but orgs that want to do this would likely have done it regardless of the use of Jira. I have my team use story points yet I don’t ever use them to measure team or individual velocity. The fact that Jira enables incompetent managers (which is not the same thing as ‘managers’, one is necessary and one is not) to be incompetent is in my opinion a fairly low-level mark against it.
The reality is that most developers don’t know what degree of organisation / visibility is required for it to even be tenable to do their job in the context of a wider organisation. ICs, and the experience of ICs, should certainly be taken into consideration when picking PM tooling, but it’s not a bad mark against an org to also take into consideration the very real needs of management, PMs, etc.
There are always going to be those people that will categorically associate management with ‘bad’ and I just simply cannot respect that opinion. It’s the equivalent of being mad at your parents for setting a bedtime. Some of the Jira hate definitely comes from people with that mindset.
I use jira, I do not use points, sprints, scrums, etc
Jira doesn't require those features. My workflow is "Ready, On Hold, In Progress, Done". It's a glorified task list with assignees, tagging, emails etc, that's corporate-wide -- no need to get random people to get accounts, everyone has one. All over our documentation and configs are references to "TKT-1234", which explains the background to a specific thing far more than an inline comment could.
It does the job just fine, I didn't need to jump through any hoops to get it working like that.
The alternate system engineers in other departments use is email. Tracking things in email is awful.
You can use Jira for far worse things, but that's not a problem with the tool, that's a problem with the culture.
I'm a developer and I like Jira. People who hate it are probably forced to use some bloated setups. We just use Kanban and the backlog and that's it. It's great if you don't turn it into a fully blow project management tool.
Exactly this. After layoffs and a small restructuring last year, we created a new project for our team in Jira and didn't include anything that had been added by upper management in the previous project, used a simplified workflow, and further changes are talked about by the team at retro. Went from a pain to easy to use.
Interesting; I think this is a demonstration of how much what seems like a "Tool" is actually "organization", because my current experience is completely opposite:
* In MS teams, I can create conversations, group chats, organic meetings, and add people (and include history) as I want and desire. I prefer it for quick discussions with my colleagues and to get a rapid problem solving or critical incident conversation where I don't immediately know who I need / what it's about, and it'll scale as I add people. I push a button and talk to people, push a button to add people, push a button to video chat, all seamless.
* Slack is structured and formal and based around enterprise-created channels and workgroups, with way too much noise in each massive channel and way too little content that's even remotely relevant to me. Outside of channels, conversations are horribly gimped: A) I can only have one conversation with each set of people, I cannot simply rename a chat and have three different chats with same people around different topics B) If I add people to an existing conversation, it will create a new chat without history (this may have improved recently as I know we sent a TON of feedback to Slack admins). Basically, to get anything done you have to create channels, which is great for "top down, I know ahead of time what I need / want to enforce" structure, but awful for "this started as a one-on-one and is now a massive discussion with 17 people"
I'm looking at some of the other comments, and it seems they have some weird gimped version of MS Teams. E.g.:
>>"Allow “create a meeting for this Teams channel” that puts any meeting chat directly in the channel."
This... is how it works for me. I start a conversation with some people, then I add people, then I click "Call", then we all video call together, then we are done and keep typing in it, repeat as needed.
> Basically, to get anything done you have to create channels, which is great for "top down, I know ahead of time what I need / want to enforce" structure, but awful for "this started as a one-on-one and is now a massive discussion with 17 people"
In Slack, you can turn a group DM into a private channel and keep the history.
That sounds like you have a very top-down organization and they have setup Slack to mirror that dynamic. Slack by itself does not have those restrictions.
Individuals can create Slack Channels (often too many channels). You can setup adhoc groups through DM and can add people to that group . You have the choice when adding people to a chat to block the history or give them full access to the history. At any point you can convert a adhoc group into a Channel and decide if it will be private or public. You can click to start a call or to start a zoom with those present in the group or channel. it's pretty seamless, too.
It sounds like the difference is your organization.
Yes. That is the very first sentence in my post :).
A lot of our presumed perspective and experience with tools is actually our experience with organizations and policies.
Conversely, majority of issues I've read here with Ms Teams, are not part of my own experience - Teams I use is way easier and more flexible and user friendly than the slack I use.
Is it the case that more startups used slack vs more enterprises used teams and that sealed in some stereotype?
1) Let a Team channel be a normal-ass chat instead of some weird forum-in-a-chat-interface. Shit gets lost. Creating a new post feels very formal and high friction, because it’ll push everything else out of view (another, minor problem: teams’ padding and whitespace is way out of control). Make it configurable! That’s ok. The weird chat-as-forum thing is fine for a very low-traffic announcements channel (and very bad for anything else) so having it as an option is alright.
2) Allow “create a meeting for this Teams channel” that puts any meeting chat directly in the channel.
These two problems force conversations away from the “Team” and into meeting-specific chats and DMs. It’s really, really bad. It silos knowledge and makes it hard to tell wtf is going on.
Teams is horrible for distributed or hybrid work because of these two deficiencies.
There is probably some feature request somewhere in Microsoft weird tech channel with thousands of comments and upvotes and some MS person appearing every three years to let us know they "are looking into it".
There were a couple years-old ones on public feature request sites last I checked. They’re ignoring them.
It’s frustrating because Teams can already do normal chat rooms, and can already schedule meetings. Just not in the most-useful places to have those two features. It’s not brand-new feature development from scratch.
Nah, you can schedule meetings (like, coordinate it through Outlook with a scheduler tool and the invite emails auto send and all that) in a chat, but not a Team channel. Chats in Teams are not in a Team (god the terminology gets confusing) but are more ad-hoc, like direct or group messages. You can pin chats but there’s no “THIS is THE ‘general’ chat for project X, this is THE support chat” et c that looks the same for everyone. The chat interface is separate from the Teams and Team channels. You can’t create a meeting from a Team channel (at least, I’ve not seen a way).
All they goddamn need is a way to permanently attach Chat rooms to a Team, as a channel, basically. The channels are these weird forced-threaded things that are more like… blogging? With comments? In a chat interface? Or a forum but it’s impossible to follow several threads because of the interface? They’re horrid and have a UI so bizarre that I’d buy it as parody.
> Jira is brilliant. It is team-led. Different teams have different approaches, [...]
That doesn't sound real. There's supposed to be some central department(s) that collect ideas from the process framework of the season or requested by customers (especially those items for levels that are not requested), add their own ideas and create a superset of that as configuration with everything set to mandatory. The result is infliced upon everyone, except of course the department that was responsible for the definition.
No I'm serious, the whole 'agile' and Jira thing just wastes my time and distracts me from the work.
I know what to do and how to do it, I don't like the whole unnecessary framework around it. Sure, tools that actually help me to do my job are good. But my job is not one that requires very specific tools. And methodologies I hate because they try to constrain my thinking.
For the same reason I really hate participating in religions, for telling me what to think, to show up in church and pretend I agree and be part of their arbitrary group with its arbitrary rules. I'm more of a free spirit. I'm the opposite of a 'team player'.
But of course people differ and I know some people love the sense of belonging and the guidelines.
A large part of my work is communicating with other teams and making sure we all fit together. Jira allows me to do that far more efficiently than phone-calls and a private notebook (like one person I know), or emails (like several)
Read as a feeling instead of a rational thought I can deeply empathise. I recently had my first experience with Jira that enforces sprints and an illogical workflow for a team that should work in kanban with several types of tickets of witch at least two should exist for any work to be getting done, often more because you need a different ticket for the managerial problem and a different for the techical part of the solution and an additional one for the analysis of the problem at hand all written up so anyone could do any task, nicely linked.
It is horrible. I just want to work. It's two lines of a fix in a config file. It does not need such a ceremony but a message on teams.
In my case this is a solution to a problem of fluctuation and growth so described processes can make everyone redundant. I bet the people set this up never even read the agile manifesto.
Well tools that actually help me to do my job, yes. But Jira doesn't. It's just an impediment.
The same with 'agile' that's just forced on us not because it is a great idea but because our idiot CIO loves her buzzwords. It's not even implemented right.
Ps I don't do any development work. The problem is they're trying to shoehorn a methodology that doesn't work for us. I'm not even part of a team that do the same as what I do. But in general i don't like the mental restrictions that having to adhere to methodologies brings.
Where do you track what plates you're spinning? When you look at some function and you go "what does that feature supposed to do", where do you look up the history? Just in git comments on the file?
Do you simply not track or communicate at all? Do you store it all in a personal notebook? Do you store everything in emails? Files in dropbox? Or do you rely on memorising everything you do, why you do it, when you do it, for who, etc?
> Where do you track what plates you're spinning? When you look at some function and you go "what does that feature supposed to do", where do you look up the history? Just in git comments on the file?
Like I said I'm not a developer at all. I don't use git for work. Nor do I collaborate on my tasks with other people. My brain is enough to keep track of things. Yet the company wants everyone to be "agile" regardless of the role.
> Jira is brilliant. It is team-led. Different teams have different approaches, some love all the features like components, versions, issue types, assignee, kanban boards, scrumms, reports etc etc. Others like my team use it with subject/description/comments. You make the tool fit what the team needs.
> Same with slack, you can create and destroy channels around your team -- anyone can create any channel at any point it makes sense -- problem at 3AM, spin up a channel to discuss it, job done. You can integrate and add plugins nice and easy.
> Remedy and Teams are led top down. They're designed to be organised, not organic. They're not built for the teams doing the work, but for the people wanting reporting. It's more about monthly KPIs than actually improving performance.
I'd say it's the other way round. Everywhere I've seen Jira, the person who can change the tool settings (e.g. make mandatory fields optional, add a transition to allow you to move a card to the column it should be in (because Jira is deny by default, you can only move things in ways that are specifically allowed) is a very distant part of the org chart from the team doing day to day work on it. "not built for the teams doing the work, but for the people wanting reporting. It's more about monthly KPIs than actually improving performance" is exactly how I'd describe Jira, given how I've seen it used (across a great many organisations, large and small - indeed I'd say switching to Jira is the most reliable indicator that a previously fun company has grown too big and it's time to leave).
Some stuff is probably just typical managerial bullshit. But the fact that Jira defaults to working as a slow, drag-and-drop interface with no undo is absolutely an unforced error.
> Never has an anti-trust move been so obvious or damaging.
Atlassian buying Trello and gradually ruining it is worse than MS giving away crappy products for free.
Your jira seems to be set up to reduce your control
My corporate jira gives me full control over the workflows, what fields are shown, etc
That's not a jira problem, it's an organisation problem
There's no way I could extract any usable metrics from my jira, but that's not its purpose. It can however tell me where we are with the new upgrades to Site 95 (waiting on the people running the fibres), or who wanted that new device in Site 5 and crucially why.
When I clicked on the site the very first opinion called Jira shit because they had 20 different boards for the same thing, 2000 tickets in the backlog and 20 different mandatory fields for each ticket.
Which is absolutely not the fault of Jira. Jira does not make you create 20 boards and per default a Title is all you need to create a Ticket. By the complaints own wording they had 2000 tickets because management refused to delete outdated and irrelevant tickets.
A new tool would not fix this since I would bet that management would insist that all 20 boards with all tickets in the backlog would need to be transitioned to the new tool. The mandatory fields are obviously also highly important to management, those need to be configured in the new tool as well.
Instead of complaining about the obviously bad management they just complain about Jira. That is, I think, very common when complaining about jira.
If one company uses a tool badly that's a bad company. But if most companies use the tool badly that's a bad tool.
Jira certainly seems to push people towards having a handful of manager users who are the only ones who can create boards/transitions or adjust which fields are mandatory, and this leads to bad behaviour - if only one VIP can create boards, they'll probably create 20 once and then never create another. "Title is all that's required" may be the default in some editions of Jira today but it certainly isn't widely used. And "transitions are impossible by default and only possible if enabled by the admin" is a uniquely bad Jira-ism that other tools in this space don't have - there may be occasional use cases where you need e.g. an action that's impossible to undo, but it's an awful default.
Well... for us every team gets a "Project" and the Team Lead is admin for the Project. The TL can then Create Boards, Issue Types, and Workflows. The Team is in control of what their Board and Workflows look like. Not some far away manager and if we do need the company Jira Admin to do something, it just needs a IT Support Ticket and that will be handled.
We set up our Board and Workflow fairly minimal. Which is probably why I don't have any problems with Jira.
> And "transitions are impossible by default and only possible if enabled by the admin" is a uniquely bad Jira-ism that other tools in this space don't have
What do you mean by that? The default Workflow in Jira is that all Issues can transition into any status.
> The default Workflow in Jira is that all Issues can transition into any status.
The default workflow in some newer editions has a transition that allows that yes. But custom workflows don't have those transitions unless and until an admin manually adds them. If the person who set up the workflow didn't think of some edge case, you're SOL.
Since the person that made the workflow is always the Team Lead we are never "SOL". It is a 2 minute thing to fix a workflow.
Sounds to me like you probably never edited the Jira workflows yourself. If it takes your company more then an hour to change a workflow then that is a decision to artificially limit things.
Also: Custom workflows start with with the "Any" transition on all states and when adding a new status it also has the "Any" transition. If that is different in your workflows then that is a deliberate decision.
> Sounds to me like you probably never edited the Jira workflows yourself. If it takes your company more then an hour to change a workflow then that is a decision to artificially limit things.
I've never been able to edit the workflow, except at one company where I had access to the "beta" Jira but not the "real" one. This is across, like, five or six different companies - again, if it were one company I'd say it's a bad decision by that company, but the fact that it's so consistently done this way tells me it's something about the tool.
> Also: Custom workflows start with with the "Any" transition on all states and when adding a new status it also has the "Any" transition. If that is different in your workflows then that is a deliberate decision.
Wasn't the case as recently as 2020 (the last time I had access to create my own custom workflow, and I'm pretty sure that was a newer version of Jira than many large companies are using). Are you using the cloud version or something?
I am using the Cloud version, but I have been using Jira over the last 10~12 Years at different companies. I can't remember a time where transitions where restricted by default. I always preferred a less restricted workflow if I am working with a I can trust, but I can't remember needing to change workflows to enable transitions from a default.
What I wanted to get across is that Jira makes it very easy to give control to the Team that is using a specific Board or Workflow. If your company don't trust their Teams with that then that is a failure of the company and not a failure of Jira.
The problem with JIRA the product vs. any instance of JIRA is feature bloat in the product has allowed for people to spin their wheels with all sorts of whiz-bang categories, labels, charts, and other nonsense.
The dopamine hit from tweaking charts and organizing digital clutter is probably the same area of the brain where the social media infinite scroll dopamine hit happens. If JIRA the product didn’t offer all these dopamine hits for doing busy-work, aka “features”, and stuck to basics then people wouldn’t be complaining about the tool and how their management/admins have implemented some nonsensical process.
I've used Jira (last job) and Linear (now). I don't really see any compelling reason that Linear is "better" than Jira. Jira was always pretty easy to use and navigate for me, and we had team-focused views for ourselves.
Even on this site, several opinions I looked at are about the idea of process or the implementation of a process—not really about Jira. And several of the ones about Jira just came off as whiny nitpicking and not actually meaningful.
Linear being strongly opinionated helps keep Project Managers (broad term for manager types) in check. Jira trying to be everything to everyone means KPI management is just a few clicks away.
I'm not going to "stan" for JIRA, but I've developed software before Jira with Bugzilla and other smorgasborgs of tools.
JIRA was a dramatic improvement at one point, however, it is bought and sold to managers, so it is unsurprising it eventually converges to managerial overengineering.
I've seen many small orgs adopt trello, slack, discord and other tools organically. I've rarely seen a small org willingly choose jira or teams; that is a choice that is almost always imposed by non-users of those tools.
> disdain for the specific tool vs. disdain for what working in a mid-to-large org
You're kind of missing the problem here - it's both and neither. It's not the tool (it's awful) or the mid-to-large org itself, it's the concept that a tool as blunt as a ticketing system can meaningfully capture software development management in a useful way.
If people just treated it as a "necessary evil" time-tracking type system to make sure people were really working when they said they were, that would be irritating but not damaging. But far too many people without a lot of mental faculties actually take it completely seriously and try to put everything in it and expect meaningful results out of it. It actually ends up being worse than "nothing at all" because it _insists_ on the "only do what can be predicted and whose predictions is measured in hours" model of software development that stupid people think encapsulates creative activities.
> the concept that a tool as blunt as a ticketing system can meaningfully capture software development management in a useful way.
The background to this is : yes it can. I worked in organizations (long pre-Jira) where we developed the bug/ticketing system specifically to drive our development management process. The two evolved in concert. The result was excellent, and sadly has never been re-achieved with any of the modern tools.
My take on this is that somebody was told that the bug system can be used to drive project management (which it can) but then implemented a bug system without any real understanding of what that means or how to achieve it.
> But far too many people without a lot of mental faculties actually take it completely seriously and try to put everything in it and expect meaningful results out of it. It actually ends up being worse than "nothing at all" because it _insists_ on the "only do what can be predicted and whose predictions is measured in hours" model of software development that stupid people think encapsulates creative activities.
You’re conflating ticketing systems with work estimation.
My team does a lightweight agile process, we don't hate it. If we used a better tool, we'd love it. We have Jira, and I don't have the energy to change it, nor do I want the responsibility to decide or suggest what other tool that should be. I've always used Jira, I have no suggestions ready. I'm sure it's easy to pick a simple tracker, like GitHub Issues, but I would not know if it'd suffice all our needs and if it would scale, and again, I don't have the immediate energy to invest time into that. But meanwhile Jira is slowly eating away at me. I think the general concepts are acceptable. It's just all the rough edges, all the stupid little design decisions, and its slowness that I hate (passionately).
> I'm sure it's easy to pick a simple tracker, like GitHub Issues, but I would not know if it'd suffice all our needs and if it would scale
The irony here is that those simple trackers scale a lot better. Jira's complexity is part of why it scales poorly - it's really bad when you have 500 people trying to use it.
- A giant board on Miro.com with a bunch of notes in frames
Of course the scaling needs are different whether it’s for just a single team or if the data needs to be aggregated into some KPI. In my experience it’s better to keep KPI publishing separate from task tracking, though
Trust me it's distain for the tool. Jira is bad on three fronts:
1. It's too configurable. It's like the company wiki. People come in, set up some random projects, processes, fields, statuses, etc. and then move on. There's rarely someone making it all consistent and sensible. This results in task statuses that can be TODO, BACKLOG, PENDING, WAITING, TO DO, etc. etc. etc. You also end up with waaaay too many fields for tasks. Arbitrary distinctions between "Tasks" and "Stories", etc. You're at the mercy of your Jira admin who will definitely make worse decisions than e.g. the developers of Phabricator or Gitlab. Hiding useful fields, adding pointless ones, etc.
2. Despite being super configurable, it can't do some really basic things you'd expect from something whose sole job is task tracking. For example you can only parent tasks 2 or 3 levels deep. A task can't have two parents. Subtasks can't be in different sprints. You can't reorder tasks by priority in the backlog.
3. Most offensively it is just incredibly slow. The main way you add tasks to a sprint is drag and drop on the backlog, but it performs so badly (100% CPU all the time) that they've had to add context menu options to move tasks to the top/bottom or to a sprint. I believe there's also an option to disable animations. A simple web page should not consume 100% of my CPU.
It's by far the worst issue tracker I've ever used.
Companies still pay for it though because PMs love the pretty burndown charts and being able to add a gazillion fields to tasks. How will they report project status to their bosses if they can't have Jira work out the exact-to-the-second estimated delivery time automatically? And by "automatically" I mean by making someone else do all the work.
My favorite is trying to figure out the subtle inflection differences between “won’t do,” “rejected,” “deprecated,” “won’t fix,” “can’t fix,” “cancelled,” “invalid,” “abandoned,” and “declined,” as well as the priority at which we aren’t doing something (um … low?)
Not only that. Once you've battled the sucky editor and have the document in confluence, you will realize that if you export it to pdf (or word) it will look like shit. So what's the point?
Disagree; Jira + Kanban is if anything even worse. Since Jira is such a pain to use and Kanban doesn't have any requirement for estimation or timeboxing, people will write one ticket that says "do everything" and work on it for 6 months. While admittedly avoiding Jira for 6 months at a time is good for the soul, when you put your head down and work on something with no context for 6 months you usually end up making something that wasn't actually wanted and has to be thrown away or drastically reworked, which ends up being more soul crushing.
No, never. I’ve stopped doing story points for this reason. When people want an estimate, I tend to chop things into reasonable same-sized chunks and do my best effort based on that. I prefer the NoEstimates approach and try to use past data to be a bit more “real” but it’s not always possible.
The truth is, if someone wants a time estimate, just do that and don’t beat around the bush. It’s too much effort to still be wrong.
It's no different than Agile or Scrum. It's just a tool, but if you put it in the hands of morons, you're going to have a bad time. Especially when there are explicit assumptions about how you'll use it built into said tool, and then said morons ignore them.
Unfortunately in any medium-to-large org, there are a non-zero number of morons.
The specific tool is often bad, working in mid-to-large orgs is often bad, and the two combined can be catastrophically bad. Poorly configured Jira on top of a poorly run large organization and you end up with an orwellian system that does nothing but punish people and squander productivity and human life.
> I always wonder how much of this sort of thing is disdain for the specific tool vs. disdain for what working in a mid-to-large org. is like and the overhead it usually brings with it.
I used to work in a largish public company (40K+ people). They had a wonderfully functional and flexible bug tracking system.
So no, at least in my experience one can be in a large org and enjoy your bug tracking tool, nothing to do with the overhead of a large org.
The current era really overestimates the benefit of using third-party cookie cutter tools. Yes they save on development cost of course. But you're stuck with something that has a million complexities you don't need and that is mostly terrible for everyone. So you pay in an infinite stream of small annoyances which add up.
There's a lot of value in building in-house tools targeted to work exactly like your team works with zero extra complexity.
And look at all the years-and-years-and-years-old jira feature requests that atlassian never bothers to implement and you have to suffer with mediocre workarounds. With an in-house tool you change it in an afternoon to do exactly what you need.
It's not for every company but companies of enough size to support building in-house tools should really give it more consideration.
We did the switch to Atlassian Cloud last year as there was no way to justify going for the 4x markup of a data center edition for self-hosting and oh boy, what a ride. The UI keeps changing around, it's dog slow, for some reason you can't copy a text from a ticket description because the pure act of clicking on the text will switch over to the editor that takes >10 seconds to load even on a high-power machine on a 10 GBit/s uplink...
Atlassian desperately needs to pause on new acquisitions and new features for at least two years and rework all of the products they acquired and unify them. Literally every Atlassian product offering has a different way of doing things, no consistency anywhere. Oh, and half of the functionality has no API, and there is no first party Terraform provider so you have to do everything by hand every fucking time.
The abusive workflow bullshit by clueless middle managers is another problem in itself, thankfully I'm in the lucky position to tell people "no, we won't do that".
I agree. Cloud vs. Data Center is a big issue that doesn't get brought up enough when bashing Jira.
DC (and formerly Server edition) are pretty good products that do their thing fine and are fast enough for typical use. Unfortunately, Server edition was discontinued and DC is too expensive, so formerly happy developers are forced to switch to Cloud edition, which is horrendously slow. Jira Cloud also lacks some loved features, such as the plaintext comment editor [0].
The biggest company I've ever worked in was 120 people, and I hated using Jira. I also hated Jira at the ~100 person company I used to work for, and the 7 person company I worked for a few years ago. Jira has a lot of problems. I've yet to find the one, true, perfect work management system, but of the half dozen I've tried, Jira is the one I like the least.
I’ve never once been able to figure out WTF actual benefit it provides over GH issues or Gitlab’s equivalent. I was once told we couldn’t use Issues because “non-developers find it confusing” but holy shit that cannot be true, have you seen how much more confusing even a very vanilla Jira is?!
It seems to me these tools should be optimized for the majority of their users (developers) and if the PMs need pretty graphs and someone else wants it all in a spreadsheet (OMFG) they could use any of a hundred integrations to extract the data and generate those without more effort than wrangling Jira.
Shit, lots of places are already paying for GH or Gitlab (or self-hosting the latter). They just don’t use that part and instead also pay for Jira or Asana or ADO or whatever productivity-murdering junk-drawer-where-information-gets-lost garbage.
I love my job and the people I work with. I hate Jira with a vivid passion. It is, by far, the worst tool I have to work with. In fact, it is the only tool I hate to work with.
It is possible to have terrible poorly made tool, and use it to commit unspeakable atrocities.
If JIRA at least had rational design underlaying poor implementation, it would give some reason to bear and hope. Instead, it is an infinite fractal of nope, the likes of which you hardly encounter outside government contract projects.
At my last large tech company we moved from Phabricator to JIRA. It was a global downgrade for actual users through and through. Engineering hated it, usage of ticket tracking went down a lot because nobody wanted to interact with that crappy tool. A good chunk of team's tasks just went into more informal google docs, sheets & slack channel bots as a result and the teams responsible for managing the tool had a hard time getting real adoption.
We were forced to get off of Phabricator because it was abandoned, but JIRA was still a downgrade in every way. Linear will eat JIRAs lunch and in a decade, it's going to go the way of HipChat as the thing that everyone used but nobody talks about.
Jira is very crud-like unless you add plugins to make it a bit better. (Unless things have changed since I last used it?) That means lots of unnecessary clicking around and waiting for slow page loads when you just want to achieve something simple.
A while back I tried an informal poll on HN, something like "What is the software you hate the most?" The majority of respones said "Jira".
I was thinking maybe I could help, that some hated software was something I myself had used at some point. But I have never used Jira. When I investigated what Jira was, I had the same thought: I thought that in this case the software is probably only part of the problem.
I worked at a large organization and yet didn't have to put up with anything Jira-like and top-down. Ticket-based development is neither necessary nor sufficient—nor even particularly effective—for coordinating software development at scale. It's a throwback to the superficially compelling but thoroughly ineffective ideas of "scientific management".
I've wondered the same thing about Microsoft Teams. Is Teams as horrible as people say, or do they just hate it because it's what they happen to use for video meetings at work? Conversely, I don't hear much hate for zoom.
> Is Teams as horrible as people say, or do they just hate it because it's what they happen to use for video meetings at work?
So, let's sum up my personal gripes (on a Mac):
1. Teams keeps locking up the dGPU for whatever reason randomly after calls, draining the battery and grilling my legs until I figure out that Teams has gone nuts again.
2. Since the macOS Sonoma update and the switch to the "new" Teams client, every time a call comes in, the ringtone glitches out (and I'm not alone in that)
3. There are three different ways of chatting with other people: Meeting chats and direct/group messages (these are summed up under the "chat" tab) and "teams" with "channels". The latter don't produce instant notifications when someone writes there, I guess because Microsoft doesn't want to deal with "I get an instant notification every time someone posts a kitten photo in the off-topic channel" complaints.
4. There is only one uploaded-files repository which means if you have a "screenshot.jpg" sent to someone, and you try to send a different file with the same name in a different chat, it will say "you already uploaded screenshot.jpg, do you want to replace this?". This is fucking bad UX, likely caused by Teams using OneDrive under the hood to share files.
5. The search is slooooow as molasses and damn useless. You have zero chance of ever finding something again, the larger the org the worse the pain.
6. No window/functionality remembers your context when you switch away. Say you click on a notification from a chat because a colleague needs an urgent answer, while you're scrolling in a team thread... you go back, and your scroll position is lost.
Teams is the only reason Chrome (well, Chromium) is installed on my work laptop: it detects Firefox and refuses to function. So does Facetime, incidentally, which I found out more recently for a family thing, and that's why Chromium is also installed on my personal laptop currently.
I assume they're both doing something unfriendly that Firefox disallows on privacy or security grounds.
It says browser not supported, must use Edge or Chrome. (Pretty sure it didn't even say Safari, but I assume Facetime must have.)
That's why it's annoying really, that it isn't just not functional (or some specific feature doesn't work) unless you disable some built-in default safeguard say, it just completely refuses if it identities your browser is Firefox. Which I'm pretty sure is nonsense. Well, Jitsi, Slack, Discord, Zoom don't have a problem implementing chat & video conferencing in FF.
We switched from Slack to Teams several years ago because we were all-in on Office 365 products. Everyone hated the change, but with stuck with it. It was slow, crashed a lot, search was abysmal and you'd have to be a masochist to use it willingly....
But they pushed out a new version recently. Now you've got Teams Classic and Teams NEW (work or school)... at least on the Mac.
It's sooo much better. Way more stable. Search is a delight (relatively speaking). We get far fewer complaints now.
Worth mentioning: We only use the "Chat" aspect, we don't use the "Teams" aspect. If we want to discuss a project, we just spin up a new chat with relevant parties and rename the channel to the project. Works great. We could never get "buy in" on the Teams aspect, nor threaded discussions. The main reasoning was having to monitor two tabs in the product. Everyone just wanted to stay on the Chat tab, so we made it work.
> If we want to discuss a project, we just spin up a new chat with relevant parties
This part I struggle with, and maybe we're doing it wrong, but to me as a PM, this way is painful.
Search helps. But then I have to remember, "Was discussion about X in the chat with people A + B + C, or was it in A + B + D's chat, or B + D's chat, or..."
We also have significant challenges with knowledge silos (not intentional, and more about a cadre of new devs being brought on) that (not the only solution) I feel that pushing conversations to specific teams when appropriate might help, improving visibility.
The worst thing that I've found with teams is the latency in a video call is _just slightly_ too high (and noticeably higher than Google meet and zoom). I find this latency to be absolutely critical in keeping the flow of conversation and preventing people from accidentally talking over each other. After seeing a forced switch to teams when the whole company was WFH, it was extremely obvious the detrimental impact it had on every meeting. It's the most basic technical aspect of the product, it doesn't matter how great the rest is if you don't nail it. That's why I hate teams.
Not silly at all cause I do the same. I wonder if it’s a Mac issue displaying modals or a teams thing. I have the same issue with slack messages so I always assume it’s a Mac problem.
Teams is nice enough when it works, but it tend to break far more than any other chat app I used. Stuff like getting the call notification (won't work on Firefox, I have to launch Chrome even though I can join a meeting on Firefox). The most annoying is that sometime it just doesn't display anything. Like no notification on my phone, or the lastest message will sometime not appear on a device.
Teams also have some very nice things going for it with it's Office 365 integration, but as a chat app it's just way more buggy than it should.
Despise is not the word I'd use either. But it's this feeling that I have with so many Microsoft's products: Mediocrity.
Something like slack really feels good and intuitive to use. It had to be to make it on its own from nothing. Most alternatives for MS products and services are much better, simply because they have to be, they don't have the installed base to coast on.
With teams it feels like it's mainly chosen because it comes with O365 subscriptions for free anyway and it's not bad enough to justify paying separately for a better product. In fact most Microsoft products have this strong feeling about them. The same with Windows, Office, Yammer, Sharepoint, Edge.. It's not great experiences for the end users, though for the IT guys it's all pretty handy because of the integration. It's that feeling of missed opportunity, that it could actually have been great if someone had cared.
I think part of this is the failure of MS leadership to set a customer-centric vision. There seems to be a lot of infighting within business units. For example, they started out ok with Edge (even though it was just a chrome ripoff) but then some low-level exec had to go and enshittify it with coupon ads and loan schemes to inflate their own department's KPIs, but totally undermining the product and company as a whole. This is really something that a company with a strong vision wouldn't permit.
I, and the rest of our dev team use Linux, and found Teams ok when there was a stand-alone client for it, but the browser-based stuff they forced on us a year or so ago was horrible. The notifications were particularly atrocious, to the point of making the whole thing unusable.
The .deb of the stand-alone package disappeared, so it seemed we were stuck with the pain of the browser-based stuff. Then I remembered archive.org and found the .deb. If anyone else is in a similar situation, it's at https://web.archive.org/web/20221130115842/https://packages....
Thanks, archive.org
JIRA is a silly proprietary system, there's just no clearly stated case case for using it when we've got open alternatives like Phorge (née Phabricator) that also see wide-ranging use.
Jira tries to solve everyone’s problem. It tries to incorporate everyone’s idea of how and what’s needed to be tracked.
I can just say from my own experience that the one that created the workflow and what fields that they absolutely must have to do some sort of follow up, have never worked as a developer or anything near a software project, and yet enforces all this garbage for their illusion of control. And yet they have none.
Just because they are higher up in the hierarchy than the people that works with the actual product.
And then there is all these managers that think that everything should be a ticket and all changes can absolutely map to a ticket. Or that everything is actually done by the guy on the ticket.
I bet when I die and go to hell, my punishment will be to fill out Jira tickets and push them through the workflow.
I share the sentiment and frustration of having to fill useless boxes.
However, as a manager, things go south very quick if you're not tracking what's being changed and by whom. You won't know what's included in your release, nor if it was tested properly. You won't know who to reach for fixes after testing or even what to tell clients when they ask if a feature/fix was shipped.
I hate overly complicated processes, but tracking things is essential.
Continuous deployment is the solution to that. You always know what is in a release because it's the one thing that you were trying to change when you clicked merge.
Overly complicated processes are just patches to try to cover up for immature engineering practices.
Bonus points for insisting on tracking everything in Jira and then not making effort to open it up to check and asking for status updates via im/mail/call.
Quite the opposite actually. My developers barely touch their tickets. Most of the updates are done rather informally. They mostly interact with git and I make sure things are tracked.
Resistance to simply reading data we already fucking have is so very weird to me in “agile” (and much of non-agile, to be fair).
Part of the trouble is using things like Jira and moving tracking-what’s-happening and chatting-about-features farther from the code than it needs to be.
> that the one that created the workflow and what fields that they absolutely must have to do some sort of follow up, have never worked as a developer
This is all configurable by the JIRA admin at your org. You're not complaining about JIRA, you're complaining about someone at your company who set up the workflows. I figured this out after bitching endlessly about JIRA at company 1 only to move to company 2 and discover everything I had hated about the process was set up by my previous boss...
The problem is when your instance has too many masters - all fields are global, then their visibility is controlled at the project level. In a big company with one instance, holy sh!t. There are so many duplicated fields, unused fields. When you go to the bulk change option, it shows you all of these and it goes for days.
It works well if you keep it under control, but word to the wise to any company. Create a governance board that's not afraid to tell a VP to fuck off with their requests for yet another ill-conceived field.
That's from the user / web viewpoint.
Don't get me started on their API. v2, v3 changes - the stuff you can't filter out that bloat responses, etc....
But otherwise, if well controlled, it is good. Or at least one of the least bad systems.
My team has done a lot of work to lean into the tool IE well defined issues, epics, tickets, t shirt sizing for pointing via 1, 3, 5, etc.
There is lots that can be improved for sure.
With this system, my team, in addition to any one else at the company, is able to click into our JIRA board and get a very high level to a very low level understanding of what we are working on.
This allows for very clear reporting structures and ensures our goals are on track with those of the company's. This also makes outcomes more measureable which is exceptionally helpful for reviews.
At the end of the year or halfway through I can go in and say: I worked on these 4 epics that are part of these two Issues which serve company goals A, B, and C. I completed x% of the tickets for each of these epics, led this entire other epic which was completed on time etc etc.
Where we run into issues is when there is a ticket that has to move between boards. The ideal situation is we just move the ticket from board to board as needed but based on the user they may or may not have permissions and have to open a new ticket linking it to the previous one. Not ideal but that's up to us to resolve to make sure the right people have the right permissions.
We ignore all the analytics IE burn down and friends. Those are useless.
Short version: Jira, in a vacuum, is neither great nor awful. It just is. But it has a complication that makes managers I want to work for dislike it, while strongly appealing to managers I don’t want to work for.
That’s not universally true, I’m sure. However, it’s been my experience.
> But it has a complication that makes managers I want to work for dislike it, while strongly appealing to managers I don’t want to work for.
I think that could also be described as Jira gives people who don't really have anything to do, something to do, but for those who are blessed with an abundance of work, Jira can be unnecessary overhead.
My primary problem with JIRA, is that there is very little support for dependency trees. I have tickets X and Y linked to A,B,C,D and nothing but an ad-hoc way of determining how they are related. A visualization and tool to assign places in a tree, are part of what keeps JIRA from being excellent...ok that AND the horrid UX.
If Jira could take a dependency tree and estimates against each item and build out a timeline and display it like a Gant chart, that would be incredible. Even better, factor in employee working hours per week and bank holidays. Even better, dynamically update the timelines based on estimate updates, delays in external dependencies, or sick days.
But actually my biggest grievance is the terrible search function. You can search for the literal title of an issue and it won't come up in the results.
Didn't our whole software industry come to a consensus to stop doing things like this because the results were fundamentally inaccurate and the invariable outcomes were stakeholders feeling hard done by and/or ICs being victimised by middle managers?
Possibly, but in my experience a lot of software development happens effectively like what I described above, except in a more manual way with more potential for error and way more effort to update dependencies when things get delayed. I'm currently working for a business-to-business company and the POs are continually pressured to come up with roadmaps plus timelines. They therefore continually ask senior ICs to give "rough estimates" of feature sets that will take months. Those roadmaps are then handed to the client, who will moan about the length of time and demand it gets shortened somehow. In some cases the product manager (who is also the MD) will make something up to tell the client, or will tell the dev team to get something done "as much as possible" in one month because the client is going live with a new contract.
Obviously it's broken and inefficient, but I'm sure it's how it goes in a lot of places.
Jira needs an admin to help manage the configuration. It's like a Swiss army knife and the reason many teams hate it is because they don't have an admin helping them get what they need out of it and keep the rest of the tool out of the way. The flexibility is both a blessing and curse. If you don't like Jira it's likely your configuration is shit, or your process is shit, or both.
This, yes, but it's also sllllllow. I'm assuming this is due to the high configurability (all those options must be a pain to cache) but that is just a guess. In any event, I moved to a company that used Shortcut (formerly Clubhouse) and it was crazy fast! Like, every action was sub 100ms. While it worked very similarly to how my previous company had configured Jira, I found myself missing some stuff, mostly Jira's backlog. My current company uses Zoho and its "Projects" module is a similar but different pain from Jira. It also suffers from being way too configurable.
Maybe I'm lucky but I have yet to work in a place where any of the organizational or project management problems could be blamed on JIRA. Not even as like a top 5 reason. I don't love many of the tools I use day-to-day but JIRA is the only one that I consistently hear and read so much vitriol about. I think there's something else people are so angry about and JIRA is getting an outsized share of the attention.
My "issue" with Jira is that it's a large, amorphous piece of enterprise software. So, there's a million ways to do things. And a million plug-ins to extend functionality.
So, when I try to do something new (to me), and I search the web, the hits are frequently outdated or related to a plug-in that I might not have access to. Makes it really difficult to do anything that isn't part of my company's baseline.
The problem with JIRA and its ilk is that they try to do bug tracking, planning, and historical data all in the same tool, when those are really separate problems.
Have a bug? JIRA makes perfect sense, you have a ticket with comments, it keeps track of how long it's been around, it can automatically move the bug through a process, etc. All these tools started out as "bug trackers" after all.
Trying to plan future work? What I usually want is some kind of lightweight graph tool to figure out task A unblocks task B, etc. This graph changes a lot over time, with tasks merging and splitting apart. I've wasted a lot of time trying to enter all this in tickets.
Want to know about work that's already completed? I would never look at JIRA. Look at your Git forge. Pull requests should have proper descriptions. The Git history will always be more accurate and detailed than a bunch of JIRA cards.
So basically, use JIRA for bug tracking, Git/Github/Gitlab for historical tracking, and I'm not sure what to use for planning. Honestly I've been reaching for Excalidraw recently.
JIRA includes integration for Github Enterprise. If a commit message or branch references an issue number, it will automatically be included in that JIRA issue.
The issue w/ jira is usually the people running it. Jira will let you customize just about every aspect of it, this typically leads to a garbage experience.
The only thing worse than Jira managed by an obsessed micromanaging manager/Jira admin is when they leave and you’re left with their godforsaken configuration that everyone hates and nobody can change.
But this is exactly the problem with Jira. It enables overachieving in doing tickets, which should never be a goal, to the detriment of things that are actual goals.
The people who make the purchase decision to pay Atlassian are a tiny fraction of those using the tool. The rest have no say in the choice that results in sales dollars. Atlassian can treat this majority with contempt because their only option is to bitch &/or quit which is a very limited amount of power. So Atlassian does treat the overwhelming majority of its users with total contempt and this is financially rational.
Right up until Atlassian and Jira become synonyms for everything bad amongst the overwhelming majority of people who have encountered it. About when "Jira-free workplace" goes on job ads. Which has got to be a pretty good strategy by now. Anyone seen it yet?
At least you can search more or less properly in network folders.
At my old work I usually left a search going from the root network folder over the weekend, scanning for some keywords, when I needed a doc none knew where it was or if it existed at all.
There was a parallel documentation system from IBM that didn't work, where the canonical docs should be. But you more or less had to know the document ID to query it. So most documents were also in the network folders spread out between hundred project folders and meeting folders.
Okay, but again, which documentation is that? Technical or business?
Because I do not see business documentation evolving with code. And depending on what the code does, business documentation could be much more important than technical documentation.
Some departments do stupid things like duplicating information. We use confluence to describe the requirements, the concepts, then point to the right locations.
Take IPs, some departments have pages and pages with the same IP, subnet, etc in
I’ve been pretty happy with Slab. Straightforward shared wiki with a good editor, governance, and integrations. https://slab.com/
I tried using README files in the repo but there’s far too much friction to get most folks to bother. Google Docs tend to disappear content due to a lack of structure.
That sounds bad, but sometimes it makes sense to optimise the process for midsize changes. The vast majority of useful work is done in midsize changes.
Lots of people like to generate a flurry of tiny commits but it's not necessarily the most productive way to work, even without much overhead per change. You can always bundle tiny changes together until it's worth it for you and other people like the reviewer to do the parts that don't scale downwards.
Speaking of Google docs, I just now had the joy of talking to a co-worker while trying to figure out the source of truth for something and we spent 10 minutes thinking we were looking at the same doc when in fact we were not! The owner had made and shared multiple slightly different copies.
> I tried using README files in the repo but there’s far too much friction
I have confluence links in my Readme, which seems to be a pretty good balance, since it's physically impossible for people to use a search bar in a wiki.
Nothing! Confluence is literally just a Wiki with a REST API and a hundred plugins. You could replace it with a different Wiki, but that won't have as much useful plugins and won't be integrated with the other Atlassian products.
I was at a company where we were forced to migrate from a simple lightweight internal tool to Rally, against my advice. It was much worse, and we migrated back within a year. Waste of everyone's time, and our issues got completely mangled and all the formatting looked like total garbage.
The tool (Jira) is not the problem. The "tools" (aka PM and process people) are the problem.
In my experience, the people who are given the responsibility and power to build "systems" and processes are usually least qualified to build the said system as they usually have no experience in and understanding of what it will mean to be working under the system. This is akin to the customer vs. user dichotomy in software development, where things are build for the customer with often detrimental consequences for the actual user.
In considering tools and processes, I believe in discussing each individual decision and process step to death by considering secondary and even tertiary consequences. Yet people making such decisions are not in a position to evaluate such consequences since they have no such understanding, capability, or desire.
This would make decision making slow when enforcing tools to an entire development organization. But, decision making should be slow and deliberate. Otherwise, as I have seen in my own company, we would be jumping from tool to tool per the latest fashion of the day. I've also seen this with the mess of WebEx, Zoom, Teams way of having online meetings, where tools keep changing for the sake of some perceived benefits with no real clear improvements.
In my experience, Jira isn't great out of the box but it's pretty good if you take a few hours to understand how to configure workflows, field configurations, forms, and boards.
For example, at my last company I had the development project configured with about a dozen different ticket states, but you created a ticket with a simple form with the title as the only mandatory field but there were optional fields for details and screenshots.
Developers could move a ticket into "in progress" or "can't reproduce". The latter transition showed a form with a mandatory explanation field, and it would automatically get assigned back to the person who created the ticket.
On completing the ticket, the developer has to put in a pull request and can only moves it to the Code Review state and had to pick a different developer to assign it to.
It sounds a bit tedious when you describe it but in practice everyone worked off a board with three or four columns appropriate to their role. They move tickets to the right to advance them or to the left to reject them. There were also automated transitions triggered by things like CI tests, deployment etc.
Jira is a perfect example of how culture influences tools. I've seen and been a part of environments where I agreed with this sentiment, and also where I felt the opposite. The difference between those places: whether a culture empowers its teams to think on their own and succeed.
In the places where I've hated Jira, it's been locked into overly complicated workflows that didn't match what I needed; into the inability to create new views that provided insight into the work; into many tedious required fields even though we didn't use that data in our work stream at all. I've been locked into "one-size-fits-all" workflow approach.
Turns out: that's pretty much all configurable! Jira doesn't mandate the use of a one-size-fits all approach. Shitty company culture mandates that.
In my current position, I have admin rights to Jira and also a mandate to keep teams empowered and processes simple. Guess what -- Jira is pretty awesome here (I use it to develop, too.) In roughly a day or so, I created an entire automated hiring process via a Jira board [1] that got us phenomenal feedback from candidates. I actively ask teams what parts of the process are annoying, and then automate them or fix them, because I am empowered to care about developer experience.
Once you're a part of a generative culture that truly cares about empowerment and enablement, you start to see how much of your disdain for tooling was actually a disdain for a culture that prevented even very useful tools from having a positive impact.
We are going to need a story for that. Be sure to set a good estimate of your effort in the form of story points. Use the Fibonacci sequence to pick the difficulty level for your story points. Your manager will then arrange your stories in priority order, Stories must be worked in priority order. At review time the number of stories and the number of points per story counts. Hurry up now.
Story points represent complexity, not difficulty. We also aim for a certain amount of story points per sprint. After 13 we leave the Fibonacci sequence and just double them. The entire team must vote on story points simultaneously to avoid affecting each other’s opinions, then must discuss the votes until we agree on a number. Stories that have sat too long in the backlog need re-pointing. Voting is now done with post-its in Miro, just to be modern.
Things are sometimes stories, sometimes epics, and sometimes tasks or sub tasks. No one knows why, nor have they found a good way to integrate them all into The Workflow.
At some places, any story higher than 5 gets split, an Epic is created and the 2 (or more) new stories are added to the new epic. I really don't get the online disdain for JIRA unless it's Microsoft employee astroturfers, almost as bad as Jetbrains and Red Hat astroturfers.
Ah, that explains why I keep being asked to split a complex feature into pointless pieces that don’t stand alone. No wonder we need so many team hours in sprint planning, to keep track of them all.
No system is perfect for sure. It's a rule of thumb. If it doesn't fit then stick with the really large story that simply cannot be broken down into manageable chunks but it should be a super rare corner case that some piece of work is so huge yet atomically consistent that there is absolutely no human way to break it down, at all, in any way shape or form.
People who complain about Jira from a user perspective should try managing an instance - hundreds of people filing tickets to change specific configurations for their project and the right knobs and levers are so difficult to find that you end up filing tickets to engage Atlassian support so they can tell you where those settings are.
I got two slides in before I disagreed with everything. JIRA does not emphasize how over why. It literally just has a text box for a description. What you write is up to you. JIRA does not discourage in-person conversation. JIRA is there to document conversations and it's incredibly good at it. Any PM tool that doesn't allow threaded comments is dead to me.
I've never spent more than like an hour training anyone on JIRA and have used it successfully for many, many years.
Confluence + JIRA have made my life sooooooooo easy..
It's a pain in the ... to control/maintain the dictionary/keywords. So if the admins are doing a good job, it's a bliss.
On top of that, I can create a quick form in Confluence (with some intelligence/dependencies) and enabling/disabling/showing/hiding other options, sections, questions, etc.
No complains from either products here. Are they perfect? No. What is?
I don’t hate Jira but I can see why people do. I’ve seen some pretty rubbish looking configurations (and done one or two myself!) so it’s definitely a giant foot gun.
That said, when it’s bad it’s because the company is trying to be too clever with it. If it’s used how Atlassian recommends, it works fine. If not, you have a lot of pain. I can’t blame Atlassian too much for their customers, either. The customer is always right.
If you have someone with the knowledge to use what's in the toolbox and the scope to build flows that support how work is done in your org, you'll love Jira, because it'll work far better for you than anything else could.
If you don't have someone like that, or if you're small enough not to want or need that yet, then you'll fucking hate Jira.
From the content of the post, it sounds Jira got used as an excuse to not interface directly with Eng. Stupid move, for any org.
I have tried all the Jira clones, and Jira is the only thing that doesn't try to turn PMing into a video game for lazy micromanagers... if you don't let it become that.
I thought I hated JIRA until I moved to other companies that don't use it.
One company allowed each team to manage tasks however they liked - and therefore each team had a different method. Other companies tried to force Trello or Asana into software engineering workflows. I now think of JIRA wistfully.
I liked pivotal tracker (https://www.pivotaltracker.com) quite a bit when I used it at my last job, but that was 7ish years ago. Presumably it hasn't gotten worse. At the time I strongly suspected that it wouldn't scale past 30ish devs. That's more than enough for many people though, and that's assuming no improvements.
Can confirm that Pivotal Tracker has gotten better since then, not worse. But it's strongly opinionated and if you aren't using something very much like the Pivotal process, it might not work for you. Personally I love it.
FYI a dozen people would be a huge team at Pivotal. 30 folks working in a single backlog is unheard of. But I hear Pivotal became a different place after Rob left, so I don't know what it's like now.
Interesting -- I've been using Pivotal Tracker continuously for at least seven years, and I don't perceive much change in that period. I think this is a good thing!
For me, the most impressive thing is that Tracker manages to be simple enough but not simplistic.
I've used a lot of tracker products, and I don't consider Pivotal Tracker to be particularly opinionated. That might just mean it works the way I prefer of course! But we do not do dogmatic methodologies, and Tracker is flexible enough to add zero friction to our process.
Phabricator (or Phorge) is pretty great on that front. I think the basic Github and Gitlab systems are also all you really need. I mean Gitlab uses it and they have 60k issues and 2000 employees.
I think the key is to have good search, which Jira does not remotely have.
I get their points, but the way everything is presented is awful. I assume that these are comments on an article or responses in a conversation, but I can't see who is responding to what. Clicking "Next" to see each individual comment is also tedious, and it means I'm going to stop reading after 4 or 5 pages. I'd rather read a single page that I can scroll through rather than an "interactive" site like this.
I read dozens of them and I found the presentation to be a fun approach. The creativity is welcome IMHO. It was immediately clear to me that these were comments scraped from various sources on the internet. Who they're replying to doesn't matter much. If you've worked with JIRA extensively, you've already heard many of these criticisms.
When it comes to JIRA, I agree, but I find Conflunce to be pretty good tool. Unfortunately, most of the people using it are not very good at writing documents or organizing knowledge in general :)
The worst thing is you just can't get rid of it. You might try suggesting a simpler tool like Gitlab, but because Jira does absolutely fucking everything there will be one thing someone just can't live without and makes the alternative unviable. Of course if the simpler tool was used from the start nobody would miss that feature.
I personally just my own backlog/todo system (both for work and non-work stuff) and consider Jira usage a necessary evil part of the job. Hopefully I'll someday work somewhere uninfected.
Within the last 2 weeks Jira has begun to do some constant refresh cycle that is killing me (this is on chrome which I've been updating regularly hoping it gets fixed). The worst part is while I'm typing in one field it will seemingly randomly refocus me to a different field and start inputting text there. Only about ~5-10% of the company seems to be affected though so it's not being actively looked at.
Now I just write all my jira stuff in a external text editor and paste it in.
I've used many tasking tools in my previous startups, Asana, Phabricator, Jira, Shortcuts... I think I liked Phabricator because it's flexible and not scrum like when you manage projects. I can see why people hate Jira.
Jira is the only tool I know that has proper permission and visibility controls.
I really don’t understand the disdain for jira, it is not great but mostly fine. Basically every other tool I have used has been worse. Heard good things about Linear but have a hard time believing that the effort to switch from jira to linear would be worth it for an org.
Name a better agile project management tool that is centrally managed, supports multiple projects and workflow types, and delivers sweet, sweet dashboards to upper managers. JIRA isn't for you, it's for your boss's boss's boss.
Sounds like the real complaint here is not about Jira but about people using Jira wrong, because they dont understand how you facilitate a productive environment for the lifecycle of the delivery across product, design, QA and developers of different stacks.
Jira has some merits, but its most common uses are for companies in which the priority is to look busy (e.g., growth startups, inefficient established companies).
For early startups that can't rely upon VC-growth appearances and shotgun-approach hiring alone, I propose a complete selection of tools, including a substitute for Jira:
1. Get GitLab. Maybe hosted initially, but eventually self-hosted if you stay in business long enough.
(a) Do code in GitLab Git. Eventually including mirroring and auditing third-party dependencies (but your first few months of prototyping you'll probably be playing third-party package system roulette, and maybe even piping curl into bash from random offshore file-sharing sites run from countries without extradition treaties).
(b) Do project management and issue-tracking in GitLab Issues, with the Boards and the structured tags, for something Kanban-ish. (And someday someone will make great integrated Gantt.)
(c) Do engineering docs in Markdown files in (GitLab) Git when you want the docs versioned alongside the code. Whether it's embedded API docs/comments, or standalone Markdown documents.
(d) Do all remaining internal documentation in the crappy-looking GitLab Wiki. Emphasize low-friction, teach people how wikis are supposed to be used, and make this this canonical go-to from which all other information can be found (including those engineering docs that are in with the code). Even notes on nearby restaurants and nostalgia can go into the wiki -- you're an early startup, enjoy the efficiency and flatness and coolness while you can. Discourage anything that looks like siloing, fiefdom, staleness, BS, etc. It goes into the wiki unless it should be branched&versioned with code.
2. Tell everyone: Everything Goes Into GitLab.
3. Unfortunately, you also need videoconf and text chat. Useful non-ephemeral data from these gets captured in GitLab, probably into the Wiki. (For example. wiki page "2024-02-14 Cat Affordances Meeting", which started in advance of the meeting with an "Agenda" section. Then, during the meeting, was put up on the screen and had a "Notes" section quickly appended. Saved, done, linkable, findable, unpolished, sufficient.)
4. Don't add more docs&comms tools/SaaSes until someone can say why it can't just go into GitLab. Don't even spend time looking into this unless you're actually feeling pain from "Everything goes into GitLab".
5. If someone ignores the rules and starts putting company data into some random other SaaS (like "digital consumer natives" tend to do), have a thoughtful talk with them about Everything Goes Into GitLab and how they feel about that. While in parallel another employee deletes the SaaS account with extreme prejudice, blocks the SaaS in the company firewall, and posts a picture of the SaaS's head on a stake in the startup's kitchenette as a warning to other SaaSes.
6. If the startup is successful, there will be plenty of time for some Vice President of Procurement, who has little idea how people work, much less how they could be working effectively, to be wined&dined by an enterprise sales representatives, and to buy loads of enterprise licenses of Ass-sauna, Jeers-a, Effluence, BS Screams, etc. Only then will you realize how good you had it before, with your early startup, and you didn't appreciate it nearly enough. You will suffer until a vesting milestone, consult with your tax accountant, and then make your escape. To do your own early startup, where the first thing you do will be to proclaim: Everything Goes Into GitLab
The only valid reasons to hate Jira or Confluence are when you work for a company that has no governance structure for them. You do have to use the tools correctly for them to not suck. This is true of all tools.
When you learn how they are supposed to be used, and use them that way, they work really well. Sadly I have only met three people in my entire career who did so. Their job titles were scrum master, release manager, and project manager. They had to learn how to use the tools because that was their job.
And so they did. They could do literally anything we asked them to. They showed us all kinds of amazing things we didn't know we could do. All because they took a few hours of training and read the docs. That's when I learned that my own parroting of "I hate Jira" was just my own ignorance showing, and I grew up a bit. I really like Confluence now; I didn't even realize it was a Wiki before.
I didn't think jira was that bad. I did think the access control/authentication that it atlassian puts on top of it is total dogshit though. one unrelated part of our org got their instance setup with saml integration to our azure tenant and it locked us out of our unrelated instance (signed up for with our work emails) for a month while 30+ interactions with their support team got us nowhere.
It's fascinating seeing 95% of comments here unloading on Jira for the completely wrong reasons. It's the configuration and how it's being used that makes the whole experience bad for many people.
You can misuse any tool but that doesn't mean the tool itself is shite, you're just using it incorrectly. If you limit Jira to just an issue tracker with Kanban it's actually pretty good.
Most people shit on Jira, I guess it deserves it. But what is the alternative? I tried a bunch of tools couple of years ago. They were all as bad as Jira or worse.
I dunno if the situation has changed since then, but I would bet it hasn’t changed much
Several of the complaints mentioned are over a decade old.
For instance, I searched for "I **ing hate JIRA too, the interface is clunky and slow and makes me angry.," and found it was from this comment from Feb 2014 [1].
It is perhaps a bit disingenuous to not to include dates.
Some people complain that I don't update my stories but more often than not I just wait so much for stuff to open on Jira that end up doing something else while it is loading the page and forget about it.
Crap, clunky interface is ingrained in their culture. There was a release mid last year that changed the comments loading to be paginated to speed up ticket page load times.
They loaded the oldest comments first...
and you had to click "Load the next 10" REPEATEDLY until you got to the newest comments.
I have since left that company and don't have to deal with Jira anymore so I'm not sure if it got "fixed" at all since then.
It was the one of the most baffling, user hostile decision I have seen made to a product, and I'm sure someone got a commendation for "speeding up the ticket load page by X%".
JIRA is a tool, it doesn't do the work for you. If someone knows how to organize, plan and track a project really well, the tool used doesn't matter as much.
When you lay down to sleep, as your consciousness loses sync between limbic system and visual cortex, the Outer Dark hisses into your temporal gyrus: vast and precise architectures of obscenity, a choir of horrified mothers giving birth to dreadful machines. It is then that you know: every measure of human atrocity pales in comparison to the stupendous cruelty of the cosmos and its capacity for sin and murder.
That's where a lot of people usually hear about Jira, but it's going to depend on your org.
People working on open source "hackery" stuff are probably much more likely to be familiar with Github / Gitlab issues, or Bugzilla. I can only think of one open source project that uses Jira; it's my only encounter with the program, and it's without question the single worst experience I've ever had reporting a bug to a project from a technical point of view.
I'm not so sure about the subversion comparison. Maybe it's out of date - someone who got started programming in the last ~10 years has probably only ever used Git, whereas plenty of organizations use Jira, as far as I know.
Not every tech-interested person has been in that kind of corporate SWE workplace. There are students, hobbyists, scientists, artists etc here. It's a big world out there!
