8 ms·

Trello, “Jira Sucks”, and Tool Dysfunction

71 points by tablet 9y ago

_pmf_ 9y ago
Managers should stick to the rule "if you complain about Jira, you'll get Bugzilla."
- gozur88 9y ago
  That would be fine with me. I thought Bugzilla was better.
hdi 9y ago
I've used Jira for about two and a half years and although it wasn't that bad for us, I can see how it might not be a good fit for every team. Anyway, we ended up using a physical board, which was reflected in Jira for remote teams. I'd take a physical board over Jira and Trello any day, but maybe that's just me.
emperorcezar 9y ago
I'm sorry. You're quite wrong. Jira does suck, not because people change their work flow, but because there are many parts that fail integrating with each other as soon as you make any settings changes.
znpy 9y ago
I have been using Jira at work for the last 10 months or so, and have been using trello for personal stuff for more than a year and a half. I dunno, but Jira doesn't looks so bad to me. To be quite honest, "Jira sucks" really looks like a meme to me, that people carry around for some reaons. I am not a jira enthusiast, nor i am endorsed/funded by atlassian in any way. Jira is a tool to me, and it does it job.
- nol13 9y ago
  I dunno if Jira sucks, but the granular subtask hour estimation it encourages certainly does. Is this really how most 'agile' shops work in this industry?
  - twobyfour 9y ago
    Not that I'm aware of. Most Jira shops I've worked in have disabled that field entirely.
    - nol13 9y ago
      Any good resources for convincing management that this is a useless practice with absolutely no benefit to real-world estimation or productivity?
      - twobyfour 9y ago
        Other than finding out about that practice in the interview stage and using it as a yellow flag suggesting that it might not be the job you want? Not really. Either management understands software development or they don't, and it's not something you can really teach them either. I don't need my managers to know our stack or even be capable of developing working software themselves, but it's hard for someone who's never spent 6 months working in the coding trenches to understand the amount of uncertainty inherent in software development.
        nol13 9y ago
        Ya, so it goes I guess. Was actually looking forward to something more organized after having no process to speak of for a year. And it's not even like the estimates get held over my head much or anything, just that putting in sub-tasks for.. 1. add input box 2. create functionality to store input box value 3. have next page display value ..and keeping track of the time spent on each step is reeally annoying.
      - sopooneo 9y ago
        I would approach this differently. The question to ask is, "How can I convince the manager who has authority to make change X, that switching to Y will benefit him/her personally? How can I show them that the change will decrease the hassles in their life and/or lead to higher compensation for them?"
- cropsieboss 9y ago
  I don't know. It's fine for keeping tasks but seems quite slow. Just clicking on create issue takes 4 seconds. Switching between issue types takes about 1.5 seconds. This should all be just simple javascript change and layout calculation but there seem to be network requests for every single click. To me, that sucks a little.
- thriftwy 9y ago
  I haven't seen an install of Jira where opening dashboard won't take five seconds and any search will take ten. I just don't see how it is acceptable in 2017, with added insult that the amount of data displayed is tiny.
  - antaviana 9y ago
    In my case, opening a Dashboard takes 2 seconds and searching the full DB for text takes also 2 seconds. However, we only have about 2000-3000 issues in various projects in our DB.
- jk563 9y ago
  I've both loved and hated JIRA. For me, it all comes down to how well set up it is. Its configuration over convention approach leads to many installations being poorly configured and often hacked together.
- dominotw 9y ago
  I think people associate JIRA with middle managers who "work" all day in JIRA and foist draconian JIRA "processes" on everyone. eg: My current manager wants us update all open JIRA tickets every morning with "current status" . Not sure why manager types like JIRA though..
  - base698 9y ago
    I hate JIRA, but I noticed something. If I tell people to do something, they won't do it. If I create a ticket in JIRA it has a much higher probability of getting done. It's not been too bad, after I got over the hate of not having real markdown and the 100 fields when a ticket is created that are mostly unused. I prefer little to no process, but the work has to be organized some how, and using git with emacs and org mode wouldn't be nice to most :)
    - _asummers 9y ago
      Not sure if you've seen the org JIRA integrations, but you can effectively do ticket management in org-mode.
- wpietri 9y ago
  The times I've see it used, Jira is purchased and configured by centralized people with institutional authority, and then given to teams to use, like it or not. I think the tool itself isn't that great. When you try to be all things to all people, it's easy to be tolerable for most and great for nobody. But the real problem is what it represents: a straitjacket for teams, used to force them to work in ways that people with political power deem appropriate. The Lean Manufacturing folks put bureaucracy into two different categories, supportive and controlling. Supportive bureaucracy is bottom up. E.g., by my door I have checklists for what I need when I'm going out running or swimming. Nobody makes me do it; I just was tired of forgetting something. Good teams do similar things, like an estimation checklist or a written-up release process. Controlling bureaucracy is top down. It's where other people use systems to force you to work like they think you should. They're used as a poor substitute for trust. People experience Jira as sucking because it's a instrument of control, and controlling bureaucracy sucks.
- didymospl 9y ago
  Among similar tools(HP Quality Center/VersionOne/Redmine/ServiceNow/Bugzilla/Trac) I have been using at work for the last few years, Jira has always been the most intuitive and user-friendly, at least from the developer perspective. The others might have caught up with it by now, maybe there are new better alternatives(please let me know about them) but I agree with the author that the most of the criticism comes from the people who tend to associate the bad processes they are forced to follow at work with the tool itself. Of course the downsides of Jira mentioned in this thread are all valid, but I don't think they outweigh its benefits.
- scaryclam 9y ago
  Having used other issue trackers over the years, Jira isn't exactly a shining beacon of excellence. The UI is hard to navigate, the screens are inconsitant, the JS breaks on occasion so buttons stop working, it's slow, has horrible defaults and is far too flexible in some areas but miserably inflexible in others (usually where flexibility would be useful). All in all, it's not a great product. It can do the job, most of the time, but costs a lot of time (and therefor money) to get it set up even close to adequately. Jira is indeed a tool, and it can do the job, but in comparison with other tools that also do the job, it costs too much for people to stop saying it sucks.
jlebrech 9y ago
JIRA sucks, but it has enough bells and whistles for control freaks to play with while you just click "done" or comment.
kennydude 9y ago
I miss using JIRA. We used Trello, but boards were changed monthly. It was a nightmare. Then Asana which emails me endlessly and it takes so long to open. And now Zube which feels weird to put things in which aren't suited to dev tickets and getting anything right in the balance
xaldir 9y ago
As a Jira administrator, I both love and hate Jira. It's versatile and quite a good set of tools when configured properly. On the other hand looking under the hood is quite frightening.
deleted 9y ago
[deleted]
falcolas 9y ago
My problems with Jira: Permissions around issues and their state are so granular they beg to be abused. Permissions aren't granular enough to allow teams to individualize their project's workflow as their needs evolve. Jira constructs like states are reused in weird ways for other functionality. My favorite is the abuse of states to try and implement kanbahn style swimlanes; states which are global to an org and can thus get odd workflows attached to them by someone else. Administered with a light touch, Jira can be fine. But it's never administered in such a fashion. NEVER.
OneFishTaco 9y ago
Been using both for years, at multiple orgs, and can say with confidence JIRA does suck. Everyone in my org had given up trying to use it, I went through the pain and don't wish it on anyone... then there's Trello, it just works expected. With JIRA, prepare to invest significant pulling your hair out if you want to use any features. It's amazingly difficult to enable the use of the Trello-like board feature. Go ahead, try enabling the "Agile" feature and see, it doesn't work out of the box!!! Have fun digging through Google to figure out why you're getting cryptic errors, only to finally figure it's because.... Oh, you have to set up additional permissions to enable it. Oh, and also enable a certain field (epics) but this needs to happen in the back-end, as it's some SQL query to enable it. Oh, but you want to sort issues by drag-drop like a real board? Nope. First go find the right permission to actually enable sorting! Oh, but it still wont let you sort! Did you forget to 'sort by ASC' in your filter query? Otherwise, no drag-drop sorting for you! Why those things aren't just enabled when you created the board in the first place, boggles my mind!
- joncrocks 9y ago
  I think the 'Agile' features were actually originally an external plugin (GreenHopper), so I imagine it's integration ended up making it a bit fragile.
coldcode 9y ago
Jira makes it easy to create a sucky tool, but the real reason is always that your organization has created a sucky process. I should know, I work for a large and instantly recognizable company and our process is waterfall in agile's clothing. Sadly we have to work in a world where we have two internal organizations, and one uses Jira and the other VersionOne and both are configured to enforce this watery scrum process.
kazinator 9y ago
> The problem is that we inevitably come to hate every issue tracking product we use. Not from the moment we make the first ticket, though.
lmm 9y ago
Tools drive the way we use them. If most people using Jira ends up with a process that sucks and most people using Trello don't, maybe it really is the tool that's making the difference. (Jira sucks because it's anti-employee-empowerment by design; everything is oriented around mandatory fields, mandatory workflows, and requiring approvals. In theory a good manager should work around this, but defaults are important. I fear the same thing happening to Trello)
maliker 9y ago
Github issues hit the sweet spot for us between trello and Jira. Although then we got 6 projects all related to one code base and switched to a homegrown system. Our main win was making sure each engineer worked on the fewest number of projects. Letting people focus improved development speed and reduced confusion.
twobyfour 9y ago
"Jira sucks" is not a useful thing to say. Yeah, Jira's default workflow isn't awesome. Yeah, it's a giant pain to configure an alternative workflow; and the learning curve to do so is ridiculously steep. Yeah, some BigCorps have configured painfully bureaucratic workflows in it. But you can also configure it with a very Trello-like workflow. Why would you use Jira with a Trello-like workflow instead of just using Trello? Well, for one thing, you get additional features even just on the Kanban board - such as swimlanes. But the most important reason is that with Jira you get a true database of your issues. One that you can query with a SQL-like language. And one that allows you to present multiple different views of the same data. For instance, we have a main kanban board for one project. We have a main board for another. We have a kanban board that contains some issues from each specifically for our DevOps person; and another specifically for our QA person. The QA person's board contains three columns that correspond to a single column in the developer's board. I can create an "epic" that contains multiple tickets (not subtasks or checklist items) that can each progress through the workflow and be deployed independently but still be grouped together under a single parent epic. And if I want to pull up a list of all Foo component tickets that were filed by Bob before June, implemented by Alice, QAed by Carol, and were released in July - and then open each one in a tab - that's incredibly easy.
- wpietri 9y ago
  I get why you're excited about this, but I think it's a mistake. One thing I've seen over and over is projects where everybody did their job and the project still failed. Why? Because everybody was put into silos. Each person could define success as doing what they were assigned. The developer built to the spec. The database person made the database work. The QA person verified that the system met the spec, and the ops person made sure the servers stayed up. No actual value was delivered, but everybody can say, "Well I did my job!" Elaborate systems like this encourage people to focus on output, not outcome. You don't have a team so much as a umber of individuals who happen to be working on the same thing. Teams are groups of people who win and lose together. They have a common goal and focus on achieving the goal. One of the reasons startups are so powerful is that early on you have a cross-functional team that is intensely focused on outcome. Everybody knows that "did my job" doesn't matter if the company's going to run out of money in a year. The incentive is toward a much deeper intellectual engagement. It's not just, "Did I do what I was told?" but "Am I doing the right thing for the user and the company?"
bshimmin 9y ago
There are definitely ways in which JIRA sucks: it's hard to configure and requires someone with special skills, knowledge, and enthusiasm (!) in order to get it right; it definitely could and should be a lot faster; navigating around it is fairly bamboozling for the inexperienced; and certainly other things besides. But, with all those caveats noted, is there actually another product on the market that does as much and is any better to use?
- thriftwy 9y ago
  I remember how at one of my previous employers tools team got frustrated with JIRA and created their own knockoff in something like a half year. Was lightning fast, not crumbling under the amount of issues and projects we had, and interface much cleaner. I understand there's a ton of complexity in JIRA that we didn't use and they didn't have to implement, but anyway there's no excuse how unwieldy JIRA core functonality is.
- everythingswan 9y ago
  This is essentially my opinion of it. I look at both Trello and JIRA as useful, depending on my use case. With a cross-discipline team focused on delivering a few things (basically epics/features/whatever) at once, I love JIRA. Working on my own, I'd use Trello. It has a similar feeling to the hatred for Excel we all have as we start to use it. So. Many. Features. When you have a team member who is a power user, it can be frustrating since they will want to lead the implementation. Then you run into a bottleneck when they are the only ones that can run/fix that report. Maybe not a great comparison beyond that. I like John's take on it that you should start with a simple, physical board. If I start with a new team that will be my preferred path. I joined a team on Asana and we simply used the list type for a project with acceptance criteria. Not a physical board but it was super basic. Over the next 3 months we started to add colored tags for epics, important links to the description during the sprint, & links in the description to related stories. When it became JIRA 6 months in, we moved to JIRA. If we would have started with JIRA there would have been a riot. But now that we know the features we need, we don't find it bamboozling. It still can be for features we're figuring out we need (I spent 3-4 hours on a simple plugin last month), but the attitude is definitely not the "JIRA sucks" mentality that I hear a lot about.
yoz-y 9y ago
I quite like Jira. Speed definitely needs improvement. But one thing that would really make my life easier would be a unified syntax between Jira issues, bitbucket comments and confluence pages.
m0nty 9y ago
ITT: people saying Jira doesn't suck when the article already acknowledged that (because the headline is not the article): > I think that [Jira sucks] is a vast oversimplification, and shows very little sympathy to the challenges faced by Atlassian (and the advantages the Trello team enjoyed). The problem isn’t Jira.
im_down_w_otp 9y ago
The biggest issues I have with JIRA have to do with it being one of the world's most inconsistent, unintuitive, and undiscoverable UX's possibly ever made. All manner of things are hidden in "..." menus, and any screen will have several such menus visible at once, but they're all different. It feels very much disjointed and like the UX is done in a deeply siloed process that considers only the most local region of the screen the user could be working in (or where a feature lives), and like no attempt is made to consider the UX as a whole. It feels like using 15 different independent apps at once that just happen to be crammed into adjacent or overlapping screen real estate, and each one is a different lens with its own side effects that come from interacting with it. Some things are randomly modal and others aren't and require you to actually load an independent details screen. The only significant consistency to any of it is the fact that it all shares a somewhat common graphical style. Despite having used JIRA for a decade or more, at no point do I ever feel like I know where I'll find something on the first try or know what's going to actually happen when I deviate even the slightest from the very, very narrow repeatable process groove I get into after much trial and error.
- foolfoolz 9y ago
  older jira versions hid less and has way more buttons. it was overwhelming and complex. how do you balance a very powerful product and simple day to day uses of it?
  - notalaser 9y ago
    That's the thing -- it's (no longer) easy at all. When accessing every other function requires guessing which hamburger menu it's hidden behind, it looks clean and easy to use, but it's not.
  - im_down_w_otp 9y ago
    It's still overwhelming and complex, so that part has stayed consistent. I imagine it starts with always considering the thing as a product, not as its features, so that you can always make sure all the work being done integrates intuitively and intentionally into the original thesis of the product. The very fact that one has to hunt through various layers of oddly organized configuration screens (several of which do almost the same thing), and has to often click on more than one "..." menu to poke around looking for assumed-to-exist functionality before actually finding it, is an indicator that JIRA might be developed as an ongoing train of user stories to create features unmoored from a central thesis. Because if it was developed like a product in total, then its metaphors would be consistent, its language would be consistent, its modes of interaction with those metaphors would be consistent, and intuitive organization would largely fall out of that.
didip 9y ago
I think this is the curse of building a popular productivity suite. Similar to MS Office popular comment, by Joel Spolski I think, everybody uses 20% of the features but everyone uses a different 20%.
alkonaut 9y ago
> When I ask this, I’ll often hear about benefits like tracking, accountability, visibility, estimation, managing dependencies, status checks, notifications, executive roll-ups, and reporting. I hear very little about improved collaboration, better insights, improved quality, more effective retrospectives, and increased team motivation / sense of ownership / clarity of mission. I almost never hear about improved end-customer outcomes. I agree with the author. Enterprisey tools for enterprisey use cases are probably detrimental to developer efficency, motivation, and probably also in some respect to end-user outcome. But what the author doesn't address is that those enterprisey behaviors aren't there for fun. There are tons of levels of management that need to see those charts. You could argue "then fix that!" but then please tell me how to do that instead of telling me what tools I could use once that is done. I'm going to argue that for a lot of enterprise development this isn't possible. I don't hear a lot about huge teams of mediocre developers developing large scale software with managers on all levels having the level of insight necessary to keep stakeholders happy - while doing all tracking in a simple trello board. Now I'm not going to argue that TFS and Jira are nice and nimble. But the alternative to these aren't Trello, they are Trello + fifteen different secret steps you need to take to complete the now ad-hoc process. "When you finish an issue you need to email the QA lead with the build number to test in, then email the required translators to fill in the necessary translations, then move a thing on a board somewhere, ...." Unless all these things are magically not required, then I very much prefer digging a deeper Jira pit where all of this is at least encoded and enforced in the system rather than in a wiki or email somewhere. It's not management that pushes these systems on developers. Management push the process (because you lose track of e.g. which translations were missing and you had an embarassing release somewhere). Developers then use the tool in response, because to developers, software is the answer.
nthcolumn 9y ago
I checked search preview and got 'Jira sucks' ahead of 'Jira success stories'. So yeah I'd say it is a meme now. I don't know if it really sucks that much. I do think it suffers from that crm configurables disease. I can't believe how much time people/companies invest in this stuff, almost certainly people-lint. Often the case is where it is adopted along with Agile as a new shiny methodology with no in-house understanding of either. In one case I've seen is my team had created a shed load of data migration issues as tasks and the business were only communicating issues to the vendor. It was a mess but it wasn't Jira's fault.
tablet 9y ago
I develop Targetprocess (JIRA competitor in general) during 13 years. And I completely agree with the article. It is EXTREMELY difficult to balance product development to have a good enough feature set and bearable complexity. Here are two very typical feedback we receive from end users: NEGATIVE. Compare to Jira Target process is way behind. No ticket has the testing phase. This is very poor by design and it is very difficult to learn, because so many things on the ticket at a time and cant locate important things like Sprint or who is assigned and in which state it is? Very badly designed system. POSITIVE. It was easy to use, and since I've been forced to use Jira instead now, I miss so many of the features Target Process had... Sigh. Perhaps some day we can convince the company go to back to TP. To be honest, there are more critical references than positive. I have concluded several rules to myself from my experience: 1. Developers hate project management tools (rightfully so, in general). Anything more complex than Trello will be ridiculed and hated. 2. Teams should be allowed to choose own tools, but then we have a lack of high-level management overview. In this situation management almost always win (sadly). 3. Any serious PM tool should be a Platform with Apps in fact. JIRA is closest to this, but it is old and legacy have its price, so it is more complex then required. I expect to see completely new tools that will beat JIRA in a couple of years (Slack of PM tools :)
- nthcolumn 9y ago
  If I had a choice it would be tp2 - that's a beaut piece of software you got there... definitely does not suck.
kelvin0 9y ago
Jira: The tool that programmers love to hate. Anyways that's how most the programmers I know and worked with tell me (myself included...).
tibu 9y ago
JIRA is really good and useful if you know how to use it. We're using it for several purposes and I love it. Administration side of it is crazy complicated, for the best things you have to be global admin - this is something they should fix (but they won't I think because it would make things backwards incompatible).
overgard 9y ago
Sometimes I think the problem is really that two things are being tied together: metrics and a todo list. Almost every sprint planning it ends up feeling like tasks are subdivided in ways that make burn down charts look better. I don't want to say developers are all special snowflakes, but the problems with time estimates on creative work is well known, and I tend to wonder if trying to track metrics on these things is fundamentally misguided.
ausjke 9y ago
Just use Redmine, it worked well for me and fully open source, though I wish it is not on Ruby, not thing really against Ruby, but this is the only Ruby software I had to run/maintain on the server.
JimmyL 9y ago
I feel like a big part of people hating on JIRA is that it creates a formal process you have to follow - something enforced by code, and not just "always move your card to this Trello column first". It’s also so tempting for middle-managers to generate bogus reports, based on metrics that the people doing the work know don’t matter. Even with that, though, I haven’t found anything else as good for linking and organizing bugs and tasks, encouraging collaboration between departments and roles, recording discussions and decisions in the place they’re made, interfacing with the other tools we use to run development, and providing a rich SQL-like way to query tickets. When setting up our JIRA, we made a few decisions to try and make life easier on ICs and hide the bad parts of JIRA: * Ignore the permissions system. By the end, all we had were site-admins (who can control billing and add-ins), regular admins (who can edit workflows) and “everyone else”. Setting permissions up properly is tricky, impacts a lot of things, and didn’t add any value to our workflows. We preferred to make use of the audit log when weird things happened, and for the most part, tell people to do the right thing. * Insist that workflows come from the teams. Individual teams were given a standard workflow when they started, but were encouraged to make it their own. Central management had to cope with what the individual teams wanted their workflows to be, and weren’t permitted to make them add statuses or transitions to make reporting easier. The only exception to this was around having to use a common set of resolution options. * Open up the admin role to anyone who wanted it. If an IC or Team Lead wanted to make small changes to their team’s JIRA, they could just come sit with someone who knew how and work it out. If they wanted to make more significant ones, they received the 10-minute lecture covering the top five things that seem safe but will in reality break everyone’s JIRA setup, and then were given admin access to go do what they wanted. In the end, some teams used a sophisticated ten-step workflow with granular transitions, and some used it as Trello – but they were all unified in one place, linkable and searchable, and had common support for discussion, auditing, and file management.
- _asummers 9y ago
  I'll add also to periodically figure out what works and doesn't work and why across the company and expand that institutional knowledge to the relevant stakeholders / documentation. Your JIRA flow should provide just a little bit of structure around your existing communication structure.
dep_b 9y ago
There's just too much in JIRA to make it easy to use. If I need to ignore 80% of the fields and buttons to work with an application it's overengineered.
vaceletm 9y ago
It doesn't have to be this way. Most PM tools are designed to have a somehow central enforcement of the process and workflow with some central admins that have ways to change that (permissions, fields, workflows & all). This cannot be anything but a failure if the central admin doesn't say NO to 99% of modification requests because there will always be this influential project manager that will come to "add this little field I need to track this stuff for $IMPORTANT_CUSTOMER". So, by design, it will either be bloated (everyone get it's change so bug template is fat) or useless because the form will be so simple that everything will need to be managed with text content in comments. That's why we (Tuleap team) propose an alternative: - You want a simple -github like- issue tracker because you are 3 in your team and just a title and a description, please go ahead. - You want a full blown, CMMI Level 5, Spice 3, what not issue, requirement, risk tracker, please let the craziest process guy do. What's the difference with Jira (and others) ? Each "tracker" (issue definition) is local to one project (of course you can template for re-use) and 100% owned by the project. You are not limited to 3 or 4 central templates that nobody can modify, you own them. Let say the "simple" team is mad of tracking which component of the application an issue is raised on or how much effort was need to complete the issue, in 30 seconds the template is modified and usable without impacting anyone else. See https://www.tuleap.org/how-easy-it-customize-my-project-trackers https://www.tuleap.org/how-easy-it-customize-my-project-trac...

71 points by tablet 9y ago

_pmf_ 9y ago

Managers should stick to the rule "if you complain about Jira, you'll get Bugzilla."

gozur88 9y ago
That would be fine with me. I thought Bugzilla was better.

hdi 9y ago

I've used Jira for about two and a half years and although it wasn't that bad for us, I can see how it might not be a good fit for every team. Anyway, we ended up using a physical board, which was reflected in Jira for remote teams. I'd take a physical board over Jira and Trello any day, but maybe that's just me.

emperorcezar 9y ago

I'm sorry. You're quite wrong. Jira does suck, not because people change their work flow, but because there are many parts that fail integrating with each other as soon as you make any settings changes.

znpy 9y ago

I have been using Jira at work for the last 10 months or so, and have been using trello for personal stuff for more than a year and a half. I dunno, but Jira doesn't looks so bad to me. To be quite honest, "Jira sucks" really looks like a meme to me, that people carry around for some reaons. I am not a jira enthusiast, nor i am endorsed/funded by atlassian in any way. Jira is a tool to me, and it does it job.

nol13 9y ago
I dunno if Jira sucks, but the granular subtask hour estimation it encourages certainly does. Is this really how most 'agile' shops work in this industry?
- twobyfour 9y ago
  Not that I'm aware of. Most Jira shops I've worked in have disabled that field entirely.
  - nol13 9y ago
    Any good resources for convincing management that this is a useless practice with absolutely no benefit to real-world estimation or productivity?
    - twobyfour 9y ago
      Other than finding out about that practice in the interview stage and using it as a yellow flag suggesting that it might not be the job you want? Not really. Either management understands software development or they don't, and it's not something you can really teach them either. I don't need my managers to know our stack or even be capable of developing working software themselves, but it's hard for someone who's never spent 6 months working in the coding trenches to understand the amount of uncertainty inherent in software development.
      - nol13 9y ago
        Ya, so it goes I guess. Was actually looking forward to something more organized after having no process to speak of for a year. And it's not even like the estimates get held over my head much or anything, just that putting in sub-tasks for.. 1. add input box 2. create functionality to store input box value 3. have next page display value ..and keeping track of the time spent on each step is reeally annoying.
    - sopooneo 9y ago
      I would approach this differently. The question to ask is, "How can I convince the manager who has authority to make change X, that switching to Y will benefit him/her personally? How can I show them that the change will decrease the hassles in their life and/or lead to higher compensation for them?"
cropsieboss 9y ago
I don't know. It's fine for keeping tasks but seems quite slow. Just clicking on create issue takes 4 seconds. Switching between issue types takes about 1.5 seconds. This should all be just simple javascript change and layout calculation but there seem to be network requests for every single click. To me, that sucks a little.
thriftwy 9y ago
I haven't seen an install of Jira where opening dashboard won't take five seconds and any search will take ten. I just don't see how it is acceptable in 2017, with added insult that the amount of data displayed is tiny.
- antaviana 9y ago
  In my case, opening a Dashboard takes 2 seconds and searching the full DB for text takes also 2 seconds. However, we only have about 2000-3000 issues in various projects in our DB.
jk563 9y ago
I've both loved and hated JIRA. For me, it all comes down to how well set up it is. Its configuration over convention approach leads to many installations being poorly configured and often hacked together.
dominotw 9y ago
I think people associate JIRA with middle managers who "work" all day in JIRA and foist draconian JIRA "processes" on everyone. eg: My current manager wants us update all open JIRA tickets every morning with "current status" . Not sure why manager types like JIRA though..
- base698 9y ago
  I hate JIRA, but I noticed something. If I tell people to do something, they won't do it. If I create a ticket in JIRA it has a much higher probability of getting done. It's not been too bad, after I got over the hate of not having real markdown and the 100 fields when a ticket is created that are mostly unused. I prefer little to no process, but the work has to be organized some how, and using git with emacs and org mode wouldn't be nice to most :)
  - _asummers 9y ago
    Not sure if you've seen the org JIRA integrations, but you can effectively do ticket management in org-mode.
wpietri 9y ago
The times I've see it used, Jira is purchased and configured by centralized people with institutional authority, and then given to teams to use, like it or not. I think the tool itself isn't that great. When you try to be all things to all people, it's easy to be tolerable for most and great for nobody. But the real problem is what it represents: a straitjacket for teams, used to force them to work in ways that people with political power deem appropriate. The Lean Manufacturing folks put bureaucracy into two different categories, supportive and controlling. Supportive bureaucracy is bottom up. E.g., by my door I have checklists for what I need when I'm going out running or swimming. Nobody makes me do it; I just was tired of forgetting something. Good teams do similar things, like an estimation checklist or a written-up release process. Controlling bureaucracy is top down. It's where other people use systems to force you to work like they think you should. They're used as a poor substitute for trust. People experience Jira as sucking because it's a instrument of control, and controlling bureaucracy sucks.
didymospl 9y ago
Among similar tools(HP Quality Center/VersionOne/Redmine/ServiceNow/Bugzilla/Trac) I have been using at work for the last few years, Jira has always been the most intuitive and user-friendly, at least from the developer perspective. The others might have caught up with it by now, maybe there are new better alternatives(please let me know about them) but I agree with the author that the most of the criticism comes from the people who tend to associate the bad processes they are forced to follow at work with the tool itself. Of course the downsides of Jira mentioned in this thread are all valid, but I don't think they outweigh its benefits.
scaryclam 9y ago
Having used other issue trackers over the years, Jira isn't exactly a shining beacon of excellence. The UI is hard to navigate, the screens are inconsitant, the JS breaks on occasion so buttons stop working, it's slow, has horrible defaults and is far too flexible in some areas but miserably inflexible in others (usually where flexibility would be useful). All in all, it's not a great product. It can do the job, most of the time, but costs a lot of time (and therefor money) to get it set up even close to adequately. Jira is indeed a tool, and it can do the job, but in comparison with other tools that also do the job, it costs too much for people to stop saying it sucks.

jlebrech 9y ago

JIRA sucks, but it has enough bells and whistles for control freaks to play with while you just click "done" or comment.

kennydude 9y ago

I miss using JIRA. We used Trello, but boards were changed monthly. It was a nightmare. Then Asana which emails me endlessly and it takes so long to open. And now Zube which feels weird to put things in which aren't suited to dev tickets and getting anything right in the balance

xaldir 9y ago

As a Jira administrator, I both love and hate Jira. It's versatile and quite a good set of tools when configured properly. On the other hand looking under the hood is quite frightening.

deleted 9y ago

[deleted]

falcolas 9y ago

My problems with Jira: Permissions around issues and their state are so granular they beg to be abused. Permissions aren't granular enough to allow teams to individualize their project's workflow as their needs evolve. Jira constructs like states are reused in weird ways for other functionality. My favorite is the abuse of states to try and implement kanbahn style swimlanes; states which are global to an org and can thus get odd workflows attached to them by someone else. Administered with a light touch, Jira can be fine. But it's never administered in such a fashion. NEVER.

OneFishTaco 9y ago

Been using both for years, at multiple orgs, and can say with confidence JIRA does suck. Everyone in my org had given up trying to use it, I went through the pain and don't wish it on anyone... then there's Trello, it just works expected. With JIRA, prepare to invest significant pulling your hair out if you want to use any features. It's amazingly difficult to enable the use of the Trello-like board feature. Go ahead, try enabling the "Agile" feature and see, it doesn't work out of the box!!! Have fun digging through Google to figure out why you're getting cryptic errors, only to finally figure it's because.... Oh, you have to set up additional permissions to enable it. Oh, and also enable a certain field (epics) but this needs to happen in the back-end, as it's some SQL query to enable it. Oh, but you want to sort issues by drag-drop like a real board? Nope. First go find the right permission to actually enable sorting! Oh, but it still wont let you sort! Did you forget to 'sort by ASC' in your filter query? Otherwise, no drag-drop sorting for you! Why those things aren't just enabled when you created the board in the first place, boggles my mind!

joncrocks 9y ago
I think the 'Agile' features were actually originally an external plugin (GreenHopper), so I imagine it's integration ended up making it a bit fragile.

coldcode 9y ago

Jira makes it easy to create a sucky tool, but the real reason is always that your organization has created a sucky process. I should know, I work for a large and instantly recognizable company and our process is waterfall in agile's clothing. Sadly we have to work in a world where we have two internal organizations, and one uses Jira and the other VersionOne and both are configured to enforce this watery scrum process.

kazinator 9y ago

> The problem is that we inevitably come to hate every issue tracking product we use. Not from the moment we make the first ticket, though.

lmm 9y ago

Tools drive the way we use them. If most people using Jira ends up with a process that sucks and most people using Trello don't, maybe it really is the tool that's making the difference. (Jira sucks because it's anti-employee-empowerment by design; everything is oriented around mandatory fields, mandatory workflows, and requiring approvals. In theory a good manager should work around this, but defaults are important. I fear the same thing happening to Trello)

maliker 9y ago

Github issues hit the sweet spot for us between trello and Jira. Although then we got 6 projects all related to one code base and switched to a homegrown system. Our main win was making sure each engineer worked on the fewest number of projects. Letting people focus improved development speed and reduced confusion.

twobyfour 9y ago

"Jira sucks" is not a useful thing to say. Yeah, Jira's default workflow isn't awesome. Yeah, it's a giant pain to configure an alternative workflow; and the learning curve to do so is ridiculously steep. Yeah, some BigCorps have configured painfully bureaucratic workflows in it. But you can also configure it with a very Trello-like workflow. Why would you use Jira with a Trello-like workflow instead of just using Trello? Well, for one thing, you get additional features even just on the Kanban board - such as swimlanes. But the most important reason is that with Jira you get a true database of your issues. One that you can query with a SQL-like language. And one that allows you to present multiple different views of the same data. For instance, we have a main kanban board for one project. We have a main board for another. We have a kanban board that contains some issues from each specifically for our DevOps person; and another specifically for our QA person. The QA person's board contains three columns that correspond to a single column in the developer's board. I can create an "epic" that contains multiple tickets (not subtasks or checklist items) that can each progress through the workflow and be deployed independently but still be grouped together under a single parent epic. And if I want to pull up a list of all Foo component tickets that were filed by Bob before June, implemented by Alice, QAed by Carol, and were released in July - and then open each one in a tab - that's incredibly easy.

wpietri 9y ago
I get why you're excited about this, but I think it's a mistake. One thing I've seen over and over is projects where everybody did their job and the project still failed. Why? Because everybody was put into silos. Each person could define success as doing what they were assigned. The developer built to the spec. The database person made the database work. The QA person verified that the system met the spec, and the ops person made sure the servers stayed up. No actual value was delivered, but everybody can say, "Well I did my job!" Elaborate systems like this encourage people to focus on output, not outcome. You don't have a team so much as a umber of individuals who happen to be working on the same thing. Teams are groups of people who win and lose together. They have a common goal and focus on achieving the goal. One of the reasons startups are so powerful is that early on you have a cross-functional team that is intensely focused on outcome. Everybody knows that "did my job" doesn't matter if the company's going to run out of money in a year. The incentive is toward a much deeper intellectual engagement. It's not just, "Did I do what I was told?" but "Am I doing the right thing for the user and the company?"

bshimmin 9y ago

There are definitely ways in which JIRA sucks: it's hard to configure and requires someone with special skills, knowledge, and enthusiasm (!) in order to get it right; it definitely could and should be a lot faster; navigating around it is fairly bamboozling for the inexperienced; and certainly other things besides. But, with all those caveats noted, is there actually another product on the market that does as much and is any better to use?

thriftwy 9y ago
I remember how at one of my previous employers tools team got frustrated with JIRA and created their own knockoff in something like a half year. Was lightning fast, not crumbling under the amount of issues and projects we had, and interface much cleaner. I understand there's a ton of complexity in JIRA that we didn't use and they didn't have to implement, but anyway there's no excuse how unwieldy JIRA core functonality is.
everythingswan 9y ago
This is essentially my opinion of it. I look at both Trello and JIRA as useful, depending on my use case. With a cross-discipline team focused on delivering a few things (basically epics/features/whatever) at once, I love JIRA. Working on my own, I'd use Trello. It has a similar feeling to the hatred for Excel we all have as we start to use it. So. Many. Features. When you have a team member who is a power user, it can be frustrating since they will want to lead the implementation. Then you run into a bottleneck when they are the only ones that can run/fix that report. Maybe not a great comparison beyond that. I like John's take on it that you should start with a simple, physical board. If I start with a new team that will be my preferred path. I joined a team on Asana and we simply used the list type for a project with acceptance criteria. Not a physical board but it was super basic. Over the next 3 months we started to add colored tags for epics, important links to the description during the sprint, & links in the description to related stories. When it became JIRA 6 months in, we moved to JIRA. If we would have started with JIRA there would have been a riot. But now that we know the features we need, we don't find it bamboozling. It still can be for features we're figuring out we need (I spent 3-4 hours on a simple plugin last month), but the attitude is definitely not the "JIRA sucks" mentality that I hear a lot about.

yoz-y 9y ago

I quite like Jira. Speed definitely needs improvement. But one thing that would really make my life easier would be a unified syntax between Jira issues, bitbucket comments and confluence pages.

m0nty 9y ago

ITT: people saying Jira doesn't suck when the article already acknowledged that (because the headline is not the article): > I think that [Jira sucks] is a vast oversimplification, and shows very little sympathy to the challenges faced by Atlassian (and the advantages the Trello team enjoyed). The problem isn’t Jira.

im_down_w_otp 9y ago

The biggest issues I have with JIRA have to do with it being one of the world's most inconsistent, unintuitive, and undiscoverable UX's possibly ever made. All manner of things are hidden in "..." menus, and any screen will have several such menus visible at once, but they're all different. It feels very much disjointed and like the UX is done in a deeply siloed process that considers only the most local region of the screen the user could be working in (or where a feature lives), and like no attempt is made to consider the UX as a whole. It feels like using 15 different independent apps at once that just happen to be crammed into adjacent or overlapping screen real estate, and each one is a different lens with its own side effects that come from interacting with it. Some things are randomly modal and others aren't and require you to actually load an independent details screen. The only significant consistency to any of it is the fact that it all shares a somewhat common graphical style. Despite having used JIRA for a decade or more, at no point do I ever feel like I know where I'll find something on the first try or know what's going to actually happen when I deviate even the slightest from the very, very narrow repeatable process groove I get into after much trial and error.

foolfoolz 9y ago
older jira versions hid less and has way more buttons. it was overwhelming and complex. how do you balance a very powerful product and simple day to day uses of it?
- notalaser 9y ago
  That's the thing -- it's (no longer) easy at all. When accessing every other function requires guessing which hamburger menu it's hidden behind, it looks clean and easy to use, but it's not.
- im_down_w_otp 9y ago
  It's still overwhelming and complex, so that part has stayed consistent. I imagine it starts with always considering the thing as a product, not as its features, so that you can always make sure all the work being done integrates intuitively and intentionally into the original thesis of the product. The very fact that one has to hunt through various layers of oddly organized configuration screens (several of which do almost the same thing), and has to often click on more than one "..." menu to poke around looking for assumed-to-exist functionality before actually finding it, is an indicator that JIRA might be developed as an ongoing train of user stories to create features unmoored from a central thesis. Because if it was developed like a product in total, then its metaphors would be consistent, its language would be consistent, its modes of interaction with those metaphors would be consistent, and intuitive organization would largely fall out of that.

didip 9y ago

I think this is the curse of building a popular productivity suite. Similar to MS Office popular comment, by Joel Spolski I think, everybody uses 20% of the features but everyone uses a different 20%.

alkonaut 9y ago

> When I ask this, I’ll often hear about benefits like tracking, accountability, visibility, estimation, managing dependencies, status checks, notifications, executive roll-ups, and reporting. I hear very little about improved collaboration, better insights, improved quality, more effective retrospectives, and increased team motivation / sense of ownership / clarity of mission. I almost never hear about improved end-customer outcomes. I agree with the author. Enterprisey tools for enterprisey use cases are probably detrimental to developer efficency, motivation, and probably also in some respect to end-user outcome. But what the author doesn't address is that those enterprisey behaviors aren't there for fun. There are tons of levels of management that need to see those charts. You could argue "then fix that!" but then please tell me how to do that instead of telling me what tools I could use once that is done. I'm going to argue that for a lot of enterprise development this isn't possible. I don't hear a lot about huge teams of mediocre developers developing large scale software with managers on all levels having the level of insight necessary to keep stakeholders happy - while doing all tracking in a simple trello board. Now I'm not going to argue that TFS and Jira are nice and nimble. But the alternative to these aren't Trello, they are Trello + fifteen different secret steps you need to take to complete the now ad-hoc process. "When you finish an issue you need to email the QA lead with the build number to test in, then email the required translators to fill in the necessary translations, then move a thing on a board somewhere, ...." Unless all these things are magically not required, then I very much prefer digging a deeper Jira pit where all of this is at least encoded and enforced in the system rather than in a wiki or email somewhere. It's not management that pushes these systems on developers. Management push the process (because you lose track of e.g. which translations were missing and you had an embarassing release somewhere). Developers then use the tool in response, because to developers, software is the answer.

nthcolumn 9y ago

I checked search preview and got 'Jira sucks' ahead of 'Jira success stories'. So yeah I'd say it is a meme now. I don't know if it really sucks that much. I do think it suffers from that crm configurables disease. I can't believe how much time people/companies invest in this stuff, almost certainly people-lint. Often the case is where it is adopted along with Agile as a new shiny methodology with no in-house understanding of either. In one case I've seen is my team had created a shed load of data migration issues as tasks and the business were only communicating issues to the vendor. It was a mess but it wasn't Jira's fault.

tablet 9y ago

I develop Targetprocess (JIRA competitor in general) during 13 years. And I completely agree with the article. It is EXTREMELY difficult to balance product development to have a good enough feature set and bearable complexity. Here are two very typical feedback we receive from end users: NEGATIVE. Compare to Jira Target process is way behind. No ticket has the testing phase. This is very poor by design and it is very difficult to learn, because so many things on the ticket at a time and cant locate important things like Sprint or who is assigned and in which state it is? Very badly designed system. POSITIVE. It was easy to use, and since I've been forced to use Jira instead now, I miss so many of the features Target Process had... Sigh. Perhaps some day we can convince the company go to back to TP. To be honest, there are more critical references than positive. I have concluded several rules to myself from my experience: 1. Developers hate project management tools (rightfully so, in general). Anything more complex than Trello will be ridiculed and hated. 2. Teams should be allowed to choose own tools, but then we have a lack of high-level management overview. In this situation management almost always win (sadly). 3. Any serious PM tool should be a Platform with Apps in fact. JIRA is closest to this, but it is old and legacy have its price, so it is more complex then required. I expect to see completely new tools that will beat JIRA in a couple of years (Slack of PM tools :)

nthcolumn 9y ago
If I had a choice it would be tp2 - that's a beaut piece of software you got there... definitely does not suck.

kelvin0 9y ago

Jira: The tool that programmers love to hate. Anyways that's how most the programmers I know and worked with tell me (myself included...).

tibu 9y ago

JIRA is really good and useful if you know how to use it. We're using it for several purposes and I love it. Administration side of it is crazy complicated, for the best things you have to be global admin - this is something they should fix (but they won't I think because it would make things backwards incompatible).

overgard 9y ago

Sometimes I think the problem is really that two things are being tied together: metrics and a todo list. Almost every sprint planning it ends up feeling like tasks are subdivided in ways that make burn down charts look better. I don't want to say developers are all special snowflakes, but the problems with time estimates on creative work is well known, and I tend to wonder if trying to track metrics on these things is fundamentally misguided.

ausjke 9y ago

Just use Redmine, it worked well for me and fully open source, though I wish it is not on Ruby, not thing really against Ruby, but this is the only Ruby software I had to run/maintain on the server.

JimmyL 9y ago

I feel like a big part of people hating on JIRA is that it creates a formal process you have to follow - something enforced by code, and not just "always move your card to this Trello column first". It’s also so tempting for middle-managers to generate bogus reports, based on metrics that the people doing the work know don’t matter. Even with that, though, I haven’t found anything else as good for linking and organizing bugs and tasks, encouraging collaboration between departments and roles, recording discussions and decisions in the place they’re made, interfacing with the other tools we use to run development, and providing a rich SQL-like way to query tickets. When setting up our JIRA, we made a few decisions to try and make life easier on ICs and hide the bad parts of JIRA: * Ignore the permissions system. By the end, all we had were site-admins (who can control billing and add-ins), regular admins (who can edit workflows) and “everyone else”. Setting permissions up properly is tricky, impacts a lot of things, and didn’t add any value to our workflows. We preferred to make use of the audit log when weird things happened, and for the most part, tell people to do the right thing. * Insist that workflows come from the teams. Individual teams were given a standard workflow when they started, but were encouraged to make it their own. Central management had to cope with what the individual teams wanted their workflows to be, and weren’t permitted to make them add statuses or transitions to make reporting easier. The only exception to this was around having to use a common set of resolution options. * Open up the admin role to anyone who wanted it. If an IC or Team Lead wanted to make small changes to their team’s JIRA, they could just come sit with someone who knew how and work it out. If they wanted to make more significant ones, they received the 10-minute lecture covering the top five things that seem safe but will in reality break everyone’s JIRA setup, and then were given admin access to go do what they wanted. In the end, some teams used a sophisticated ten-step workflow with granular transitions, and some used it as Trello – but they were all unified in one place, linkable and searchable, and had common support for discussion, auditing, and file management.

_asummers 9y ago
I'll add also to periodically figure out what works and doesn't work and why across the company and expand that institutional knowledge to the relevant stakeholders / documentation. Your JIRA flow should provide just a little bit of structure around your existing communication structure.

dep_b 9y ago

There's just too much in JIRA to make it easy to use. If I need to ignore 80% of the fields and buttons to work with an application it's overengineered.

vaceletm 9y ago

It doesn't have to be this way. Most PM tools are designed to have a somehow central enforcement of the process and workflow with some central admins that have ways to change that (permissions, fields, workflows & all). This cannot be anything but a failure if the central admin doesn't say NO to 99% of modification requests because there will always be this influential project manager that will come to "add this little field I need to track this stuff for $IMPORTANT_CUSTOMER". So, by design, it will either be bloated (everyone get it's change so bug template is fat) or useless because the form will be so simple that everything will need to be managed with text content in comments. That's why we (Tuleap team) propose an alternative: - You want a simple -github like- issue tracker because you are 3 in your team and just a title and a description, please go ahead. - You want a full blown, CMMI Level 5, Spice 3, what not issue, requirement, risk tracker, please let the craziest process guy do. What's the difference with Jira (and others) ? Each "tracker" (issue definition) is local to one project (of course you can template for re-use) and 100% owned by the project. You are not limited to 3 or 4 central templates that nobody can modify, you own them. Let say the "simple" team is mad of tracking which component of the application an issue is raised on or how much effort was need to complete the issue, in 30 seconds the template is modified and usable without impacting anyone else. See https://www.tuleap.org/how-easy-it-customize-my-project-trackers https://www.tuleap.org/how-easy-it-customize-my-project-trac...