this list has some good items on it but it's very poorly organized. don't mention 3 different things as one item (looking at you number 11)
Why Jira Sucks
371–380 of 530 posts
Re: Why Jira Sucks
#372When I got my first job reporting to a non-technical executive and had authority to pick the PM tool, I thought this was my chance to find the Tool That Didn't Suck. Going down that rabbit hole led me to the sad truth that it'll be impossible to make a project management tool that the engineer likes until the engineer stops perceiving project management data entry as busy work. Finding a new tool ameliorates this until the novelty of working in a new UI has worn off.
Engineers are an autonomous bunch, and the best coders among us despise doing anything that isn't actually writing code. Unfortunately, like doc writing, there is more to being a good engineer than writing code.
Re: Why Jira Sucks
#373I'm no fan of JIRA, but why are we all using it if we hate it so much?
Re: Why Jira Sucks
#374Jira sucks but it's not because of these reasons. In fact if you fixed each item here, it would be worse. Jira sucks because it is unopinionated and infinitely customizable. As a result, everybody who believes they've discovered the perfect project management setup (spoiler: they haven't) is empowered to cook up their vision via an inscrutable set of customizations. This leads to a bunch of inconsistencies between pr…
There is no magical one-size-fits-all project management setup. Having a tool that is customizable to match your team's workflow is a great win in my book. I've never encountered any organizations where there is endless bikeshedding regarding Jira. Would you care to give an example?
Format of labels; what is an epic, vs a version on an epic; what do swim lanes represent; do you tag cross team dependencies etc
Re: Why Jira Sucks
#375Earlier quoted context omitted.
> And developers are expensive as hell. Not expensive enough apparently, because management will happily tolerate meetings where nothing happens except the whole team fighting Jira. I recently had to replace my web browser because it reduced the time to load a ticket from 4 minutes to 10 seconds due to some caching issue. Entering a date/time on a non-English locale never works. Whenever I try to leave a comment with…
My primary advantage over the Scrum Master that I replaced was hand writing all the required JIRA changes during the meeting, and doing them on my own time later. I was a hero! Highly recommended.
That would be great. On a client project a few years ago I effectively bullied the product owner into doing that.
We were a few weeks away from a launch. I had sat down with our designer and we made a list together of about 30 changes we needed to make (“this is the wrong blue. This is 2px too big. Etc). The product owner wanted me to put all the changes through our normal process - make a jira issue for each one and we can do task estimation as a team and assign them, and so on. But most of them were tasks that would take a few minutes at most. (Some of the problems I fixed live while working with the designer). Our launch deadline was fast approaching and it would have taken more time to write a good jira ticket than it would to fix most of the issues - let alone discussing them as a group to estimate. While arguing he ended up showing his cards by admitting that the main reason he wanted everything in jira was for reporting. How else would upper management know that we were making progress? I said that sounded like his job, not mine. And he begrudgingly agreed and took my plain text list and dutifully retyped everything one by one into jira tickets. And then marked them all complete a week later when I’d fixed them all.
I think that experience killed the last bit of respect I had for Agile as a methodology - at least as it’s practiced in the wild. If we were using something lighter - like trello - I don’t think I would have resisted so much.
Re: Why Jira Sucks
#376To me, what sucks about JIRA (and would suck about any well-designed tool that replaces it) is not "feature x" but the entire JIRA mentality. All of it. It encourages micro-management. It encourages more and more process. It is the enemy of getting better at the DORA metrics, which requires streamlining process. tickets in JIRA are not the work itself, never was and never will be, it is a LARP of the work, but it get…
I also don't particularly like Jira. The problems you have, however, seem to be with the very idea of tracking what needs to be done, has been done, or really having any kind of process at all by which a team coordinates their efforts. That's a very different kind of problem. Unless you spend your career work on projects where you're the sole engineer and the PM/PO doesn't know what they're doing, I think that you're…
There needs to be a balance between productive work and management overheads. I've worked at hundreds of organisations as a consultant, and what I've found works is the following: 1 manager per 5 real workers where each worker spends 20% of their time on meta-work such as change requests or project tracking.
I've seen many examples of both extremes:
Sometimes I see people working totally unsupervised, essentially just playing and tinkering with whatever random technology seems interesting to them that day. This can be a huge waste of the company's money. Surprisingly often these people are counter-intuitively very productive despite the apparent time wasting. If you take away the 20% management overheads, someone being unproductive 20% or even 40% of the time is either the same or only slightly less productive overall!
On the other hand, the bureaucratic hells of 80%-90% overheads are all too common. These are the organisations where managers would say with a straight face that the floggings will continue until morale improves. These places can be so soul crushing that all of the talented staff leave for better jobs, which is not only a brain drain but also leaves the worst employees behind. Eventually management redoubles their oversight to try and squeeze some productivity out of the remaining dregs, but this just results in even the mediocre staff jumping ship, leaving only the most unskilled, unmotivated, and unproductive staff remaining. Jira often becomes one of the whips used in places like this to flog the remaining unfortunates.
TL;DR: Some management is required but the extremes are bad, and the extreme of too much management is much worse.
Re: Why Jira Sucks
#377To me, what sucks about JIRA (and would suck about any well-designed tool that replaces it) is not "feature x" but the entire JIRA mentality. All of it. It encourages micro-management. It encourages more and more process. It is the enemy of getting better at the DORA metrics, which requires streamlining process. tickets in JIRA are not the work itself, never was and never will be, it is a LARP of the work, but it get…
I fully agree that the problem is the "JIRA mentality". Specifically, that a developer should be managed with a task list instead of giving them roles/responsibilities in the organization and letting manage the tasks themselves. Sadly, almost all project management tools fall into this trap. A whole different type of tool is necessary to get us out of this rut.
Re: Why Jira Sucks
#378Earlier quoted context omitted.
I 100% disagree. Fixing a bug or delivering a feature where you haven't documented the process, (how the criteria were decided, when it was tested and deployed) is as good a running a web site nobody visits. JIRA hate comes from the bottom up. Developers don't like having to have their work parceled out so specifically. But it's not for them. It's for managers and stakeholders who have to report progress and who are…
I disagree back, but at a different place. "who have to report progress and who are responsible for budgets." is the real problem. It's crazy that progress on engineering is measured in the number of tasks completed. This was one of the points of agile in the first place (to deliver user-stories, rather than engineering tasks) but it has mostly been lost since then, because people who are managing engineers don't kno…
> The right way to do it, imo, is to put your faith in a tech lead and a trusted team to deliver it in a timely fashion
I've been on both sides throughout my career, as the engineering lead sometimes, and as the project manager other times, and let me say, this is often just results in blowing estimates and deferring uncomfortable conversations until after things blow up.
Let's take two projects. Project A is estimated by the eng team to take three months to complete. It's not broken down into tasks that are individually estimated and tracked. Just one monolithic task: Do Project A. The project manager says "go!" and then leaves the tech lead to basically run open loop, maybe with a monthly "So, how are things going, eh?" conversation.
Project B is estimated by the engineering team to take three months, but is then broken into small week-long sub-projects, and days-long sub-tasks, highlighting dependencies. After stacking the tasks up and assigning them to the team, it looks like the project will actually take four months. Throughout development, new tasks are created as bugs are found and assigned priorities. The project manager and eng lead watches the finished/remaining task lists daily or weekly, and can easily tell when something is taking much longer or much shorter than expected, and what other parts that depend on that will be delayed.
Which project do you think has the best chance of making its estimated complete date? If the complete date is actually a deadline, which project can be more easily re-sized half way through if we need to cut scope in order to make it? Which project can the team's boss's boss's boss more easily obtain status information about? How does anyone besides the eng lead know whether Project A is even done?
Re: Why Jira Sucks
#379I got pulled in as the acting sysadmin of an on-prem atlassian suite at my last job after the I.T. dept lost everyone who knew how to use linux. The worst part of doing upgrades by far were the 3rd party addons everyone had added to Confluence etc, they always screwed up the upgrade process.
I didn't really mind using JIRA to track my daily dev work, it seemed fine to me. It was annoying that each team had different custom fields etc and seemed a bit unwieldy in that respect.
Re: Why Jira Sucks
#380Earlier quoted context omitted.
>My personal theory about Atlassian: they have realized (like SAP did before) that once you convinced management to use your product you no longer need to worry about what the users think. That's all enterprise software in a nutshell. And a huge reason why things like Slack and Trello became so popular. They targeted users first without having to get the enterprise to buy it up front.
I think trello is fine. Its so simple and fast and not trying to overachieve. Or did Atlassian already screw it up?
Not really, but they did recently migrate the login to Atlassian so what was once a quick one-step process becomes a multi-page, multi-redirect mess.