22 ms·

To 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 enc

To 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 gets taken for the central thing. This is an illusion. Fixing a bug without filing a JIRA ticket is in itself progress. Moving a JIRA card without any other change is not. Yet the second is what's visible and therefor what's rewarded. Any problem gets solved with "more JIRA " which stops working when the remaining problems are caused by too much JIRA. And yet they keep trying, because it gives "control". JIRA is a like metastatic tumour that will grow until it kills the host. In case the cancer metaphor didn't make it very clear, I don't like JIRA much. Yet if JIRA were to die today, the middle management who live by JIRA would replace it with something else equally bad, if not worse. Filling in missing features won't and can't fix that.

mnd999 6y ago
100% this. JIRA is bad because it encourages managers to use it to do stupid things, not because it’s inherently bad software.
- deleted 6y ago
  [deleted]
- deleted 6y ago
  [deleted]
- j45 6y ago
  We can say laptops are bad because they let people create bad software too. Jira is far from perfect but there isn’t much that solves what it can in an integrated manner. Sometimes complex problems need complex tools to manage them. Maybe some problems are too simple and basic but imagined to have complexity and end up in an over engineered Jira setup?
  - mnd999 6y ago
    Permits and encourages are quite different things though.
    - j45 6y ago
      I'd say less encourages.. And more easily enables. You know the saying that money doesn't change people.. It reveals what already there... Same ca be said to let people make the mess they already probably make. A disciplined workflow in any technology takes effort and thought. I don't feel like I've ever stopped trying to improve it. Sometimes with jira, other times in spite of it.
7thaccount 6y ago
I only used JIRA briefly and it took up way too much time to adequately document our work. I didn't want to leave any work out as I wanted to show all the work being done. Eventually my manager just wanted some very high level stuff absent of any detail and it mostly died out. My new manager just wants a few bullet points once a week on what you've been up to. I feel like I can convey the same information in like 3 minutes instead of using a complicated tool. The advantage is JIRA automatically tracks this stuff for you as opposed to email. I think it mainly caters to micromanagers and allows them to justify additional head count "look at how large our back log is". It doesn't matter that 99% of the backlog isn't very relevant work and hasn't been touched in 2 years for a reason.
polote 6y ago
Any better software to replace it ?
- troyintokyo 6y ago
  Maybe try with zentao.pm for a scrum tool, self-hosted, open source version available.
- contravariant 6y ago
  I don't know if better software can replace stupid management but I've been quite happy with Youtrack. That said you can do some extensive micromanagement with that as well, though it requires some coding to do the truly intricate stuff, which just might be enough to prevent the managers from getting any funny ideas ;-)
  - keithnz 6y ago
    it's weird why youtrack doesn't come up more often in these types of discussions. It's pretty good, and interestingly enough they now have a "lite" ui mode to simplify it. It's not perfect though, but I've found it hard to find anything better.
- d23 6y ago
  Napkins and crayons.
- deckard1 6y ago
  There are literally hundreds of competitors out there. But first you have to describe what you like about it. 10-15 years ago everyone would have used something like Request Tracker (RT). There is Redmine, Pivotal Tracker, Trac, Bugzilla. Those are just a few that I recall using. I've probably used more than that. https://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems https://en.wikipedia.org/wiki/Comparison_of_issue-tracking_s...
specialist 6y ago
Exactly right. Our folk wisdom metaphors for QA/Test and change management are wrong. Sure, given enough thrust, even pigs can fly. But polish a turd and it's still a turd. [1] JIRAs turrible implementation isn't even as bad as the CRM, ERP, enterprise products of yore. Turrible, sure. But I've seen worse. Much worse. [1] I was a QA Manager for a while. Someday I may publish (explain) the play books my teams used for shrink wrapped releases. (Spoiler: I replaced a lot of heavy weight CRUD based mgmt with lightest weight artifacts. Like just printing all the bugs, taped to the wall, and using approval voting to prioritorize.) Until then, Bryzek's new "testing in production" strategy is the only QA/Test workflow that seems directionally correct in our new agile SaaS world. https://www.infoq.com/podcasts/Michael-Bryzek-testing-in-production/ https://www.infoq.com/podcasts/Michael-Bryzek-testing-in-pro...
- devdas 6y ago
  That's not a new strategy.
msla 6y ago
I agree, but it will never change. Jira is middle-management-ware, a term I made up (I think) for software that serves the needs of middle management, or, at least, the needs middle management thinks it has, which comes to the same thing as long as you're selling to them. What are those needs? Metrics. Being able to see who's doing what, and how quickly, and what still needs to get done. Being able to make charts and graphs and summarized reports for the next-higher level of management, so they can say that their team is productive and their team isn't falling behind. It also serves the needs of the companies, like Adaptavist, which have attached themselves to Jira to sell add-ons and generally bring the state of the software up to where middle managers (in my experience) think it ought to be out of the box. I could imply that this is deliberate, that Atlassian is Not Adding some features to scratch the backs of those other companies, but That Would Be Wrong, I'm sure.
tootie 6y ago
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 responsible for budgets. If devs aren't working on priority items, are off target to timelines, are not following QA process or not following agreed specs then the company could be losing money. And developers are expensive as hell. And I've also never worked anywhere that had a better option than JIRA.
- TheFunkyMonk 6y ago
  I'm a developer and I can't remember anything so I love JIRA. I just grab a ticket and have everything I need to work on it.
  - SideburnsOfDoom 6y ago
    You are an assembly line robot.
    - kiaulen 6y ago
      This doesn't refute the GP's point though. I've done both the very light management and very heavy Jira, and Jira makes it easy to track what's actually going on. If you want to know what a coworker is doing, you can just check Jira. If you need more work, you don't have to go to strategy and take their time, just look at the backlog.
      - SideburnsOfDoom 6y ago
        > Jira makes it easy to track what's actually going on. No it does not, and I said that above more than once. it makes it easy to track what's in JIRA, that's all. To the extent that it's accurate, it constrains what's "actually going on".
Terretta 6y ago
Have you read David Allen’s Getting Things Done and looked at that system? You have stuff to do today, stuff to do tomorrow, and stuff you might or might not do. Each day you roll the active lists forward. Squint, and it’s just personal Kanban, with TODO and DOING, along with PARKING. These core mechanics work. Where everything goes sideways is when anyone tries to turn those core mechanics into a work breakdown structure fit into a project management iron triangle, per your middle management point. Of course, middle management is just trying to lie to senior management that writing software isn’t invention because invention isn’t predictable — but senior management wants perfect predictability so they know they’re hitting their bonus, by pleasing C-level execs, whose packages depend on pleasing shareholders. Everyone’s building a Jenga tower of predictably hitting the numbers. So if you don’t like JIRA, blame shareholders. :-)
- Closi 6y ago
  One size fits all never works in reality. Jira / Kanban works for some projects while Waterfall works for others. Some projects need high levels of governance while others move faster with low levels of governance. Some projects can get away without time-commitments, but others have dependencies and must hit deadlines, and this must be tracked. And just because GTD is great for managing my personal workload, doesn't mean that it's great at coordinating the work of 100 people. (I say this as a person that generally believes in Agile, is a huge proponent of GTD, and have also been on a dev team where Agile and Kanban was applied where traditional Prince2 would have been a better fit).
- benzible 6y ago
  I agree with your larger point but pointing to GTD as evidence that the "core mechanics" work is questionable. Many of its biggest advocates have abandoned it. > Just as G.T.D. was achieving widespread popularity, however, Mann’s zeal for his own practice began to fade. [...] Productivity pr0n, he suggested, was becoming a bewildering, complexifying end in itself—list-making as a “cargo cult,” system-tweaking as an addiction. “On more than a few days, I wondered what, precisely, I was trying to accomplish,” he wrote. [...] It seemed to him that it was possible to implement many G.T.D.-inflected life hacks without feeling “more competent, stable, and alive.” [1] https://www.newyorker.com/tech/annals-of-technology/the-rise-and-fall-of-getting-things-done https://www.newyorker.com/tech/annals-of-technology/the-rise... (or https://beta.trimread.com/articles/59839 https://beta.trimread.com/articles/59839)
kjd1231 6y ago
What bothers me is if I use JIRA, why do I have a meeting every single day telling you what I'm working on. If you care, look at JIRA.
- joegahona 6y ago
  To discuss blockers and what you'll be working on that day. Also many engineers aren't good about updating tickets, ruining it for everyone.
  - kjd1231 6y ago
    I plan on working on the tickets assigned to me on that day, yesterday, and the next day. If I have blockers I'll type up a slack message. It's not that hard.
    - deleted 6y ago
      [deleted]
  - Andys 6y ago
    In some cases, maybe they would be better at tickets if not forced to use JIRA.
    - joegahona 6y ago
      Yeah, no arguments from me. I'd rather watch someone read a book than use Jira.
  - timka 6y ago
    That's the problem. You have to actually use Jira to get any value out of it. And better use it properly. That is do it accordingly with your process or the lack of it.
ogre_codes 6y ago
> Fixing a bug without filing a JIRA ticket is in itself progress. When I see comments like this I have to wonder if you've ever worked on a team with more than one person on it. Without some kind of ticketing system—JIRA, Pivotal, heck Trello—How do you know a bug is getting worked on? How do you even know which bugs are a priority? Are the designs complete for the next feature I'm building? How does QA know to review your changes? (Yes QA is still a thing in some places and for good reason) When I was a solo dev, I would meet with the rest of the stakeholders weekly and establish what I was working on. But on a bigger team this quickly becomes impractical. Even with the 8 person team I work on now I'd have no idea who was working on what without having some kind of tracking system.
- Closi 6y ago
  I assume one of the use-cases for this is that they found a bug, quickly fixed and wrote a test case, and then pushed it to Git without raising a ticket themselves and then solving the ticket. With an 8 person team all sitting together, someone can just shout across the table and ask someone else to resolve an issue without raising a ticket too. Are you solving ticket A but need another person to help you with a bug you discovered in the API that the person across from you wrote and can fix in 2 mins? Sometimes they just do it and don't raise a ticket. If management likes to mark you on tickets, you might as well raise the ticket. I work at a big company, and every time the IT Helpdesk does a password reset they open a ticket, then mark it as closed, every time they do a password reset (because they get marked on how quickly they close tickets). Believe it or not, median resolution time for a raised support ticket is in seconds, despite it usually taking days if you open a ticket for anything yourself! 8 person teams are usually the recommended max team size anyway under Agile (two pizza team).
  - ogre_codes 6y ago
    > someone can just shout across the table and ask someone else to resolve an issue without raising a ticket too. I rarely see my team-mates in person at the moment to shout at them. If I did, they would likely tell me to fuck off because they are busy with some other task. The only sort of issues where it's appropriate to drop what you are doing and immediately fix it are the most severe issues which need to be fixed right now. > I work at a big company, and every time the IT Helpdesk does a password reset they open a ticket, then mark it as closed, every time they do a password reset (because they get marked on how quickly they close tickets). In general, if documenting an issue (of any sort) is more work than resolving the issue, you shouldn't bother documenting it. But as a developer, many of those easy to fix issues are found by people who don't have the skills or resources to fix them. The best way for someone to communicate those problems is usually some kind of ticketing system.
LanceH 6y ago
I just had this discussion this week. I'm doing work in Jira to build metrics, rather than metrics being tracked from what naturally occurs in Jira. While I understand that most of these problems come from the setup and the decision to use Jira a certain way, I feel the system itself encourages busy work. As a developer, I've felt the Fogbugz way of doing this most closely mapped to my natural workflow. It is also built around the concept of a single person "owning" a ticket, providing a natural flow from person to person through the lifecycle of a ticket. This can be done in Jira, of course, but it is a mental drain as it requires more bookkeeping. edit: I guess what I'm saying is that Fogbugz in particular is a bit more opinionated and lines up with what I think is good. Jira naturally guides management to all sorts of extra crap.
_5yoy 6y ago
Every single job I've worked that used Jira, also used google sheets to "map" actual work to Jira work. It has always blown my mind. All the meetings to update the google sheet, and then to update Jira, and then to ask why the two aren't in sync. It feels like I'm taking crazy pills. Why are we using a manual tool (google sheet) to keep track of the work, that's in our work tracking technology? What?
- redisman 6y ago
  Because there’s so much friction to do anything in Jira. It’s horrible for any kind of planning or really anything that’s not set in stone. I just keep a text editor with my current and next tasks and then update jira at the end of day based on it.
blinktag 6y ago
Agree 100%. JIRA is supposed to be a means, not an end itself. Half of my organization believes they are generating value by adding new issues into JIRA. JIRA helps reinforce a dogmatic attitude that the "hows" are more important than the "whys", and thus issues that could be succinctly described in 20 words get expanded into templated "given/when/then" verbiage. One of the core Agile principles is "individuals and interactions over processes and tools". JIRA is more-or-less value neutral, but the management caste, possibly fearful of the sort of healthy conflict that comes with negotiating the priority of features and fixes, tends to resort to inputing all their information into JIRA believing that it's a substitute for actual communication. Every Agile resource I've read has emphasized the point that nothing is equal to actual conversation between stakeholders. Whether it's JIRA or one of its competitors, when you have a tool that discourages conversations or pretends to act as a proxy for collaboration between stakeholders, you're going to court failure. Easy to blame JIRA, but it's this whole tool-based mindset.
tpmx 6y ago
We used to call that anti-pattern "playing Jira Tetris" at a previous workplace. It's excellent at the creating the illusion of productivity. Some people really fall into the trap deep.
deleted 6y ago
[deleted]
wpietri 6y ago
Exactly. Computers having infinite capacity is sometimes harmful. One of the things I like best about kanban approaches, especially with physical cards is that they discourage putting in too much. When I look back on previous boards (e.g., [1]), my main thought is we still had too much room. We wrote up and carried along so many cards we never got to. But even so, that's way better than something like Jira, because the limited board meant limited opportunity to distract ourselves with meta-work. [1] https://williampietri.com/writing/2015/the-big-board/ https://williampietri.com/writing/2015/the-big-board/
rasengan0 6y ago
What really sucks is the cheeryleading and evangelism for it almost like a cult by the very people who are not responsible for resolving issues. Side channeling by email/phone with expenditure of social capital to devs in the know is quicker with our mutual wink wink agreement to file and close the Jira ticket to appease the higher ups above. Absolutely ludicrous.
musicale 6y ago
Jira is not completely useless: it gives people who usually add negative value to the project a way to appear busy and productive, with associated rewards and promotion opportunities.
Sodman 6y ago
The biggest problem with Jira, is that they give you the gun and the bullets to shoot yourself in the foot, while trusting you not to do it... The reality is that most teams (or let's be real, managers) can't be trusted not to shoot themselves in the foot here. Adding more features and more process in general is going to be a net negative for developer productivity. But how well Jira (or similar tools) works for you is completely up to how you use it. Most teams I've seen that hate Jira et al usually have an overly complicated process, with far too many "states" for a ticket, a million mandatory fields, multiple assignees, etc. This naturally results in people spending far more time in the tool, which is time they could be spending actually doing productive work. Conversely, teams that like Jira tend to have very few ticket statuses/fields. Standups are quick, sprint planning is quick, everyone wins. Unless your job was moving things around in Jira for 20+ hours / week... in which case you'll need to find something else to do.
deleted 6y ago
[deleted]
bww 6y ago
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 probably going to have a difficult time if you can't reconcile yourself to the utility of this sort of process.
- jiggawatts 6y ago
  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.
aard 6y ago
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.
- eddieh 6y ago
  The irony is that I always had my own task list that I kept in parallel to Jira that allowed me to break a Jira issue down into subtasks, subsubtasks, down to any depth of n(sub)-tasks. The best part was that there was no "process" for my task list. It was always just TODO and DONE. Nobody had to review my list or approve it and I could delete and add entries as needed with zero friction.
jayd16 6y ago
>it is a LARP of the work This is the major problem I see. Just like misleading code comments pollute a code base, bad tickets and fantasy tasks pollute any useful information you might get from a ticket older than a couple weeks. If we're really being agile "moving something to the backlog" would just delete the ticket. If its important enough, you'll write it up again.
catears 6y ago
I work in the med-tech industry and Jira is a very good fit for that industry. Most compliance issues are solved by defining a way of working that uses a project management system like Jira. Someone else read how to label a product with CE-label and HIIPA, and all I have to do is report my work in Jira. Don't have to understand CE-labeling or HIIPA. For compliance it must be possible to find who made a change, why they made that change, and how they validated and tested that change. In a heavily regulated industry like medical, it is very useful to have a tool like Jira when the audit comes up. I still accept your point tough, if you need to go fast and break things (you know, innovate and prototype things), jira is a real blocker and the "jira mentality" slows things down, for better or worse.
x87678r 6y ago
Its Jira combined with outsourced or contract developers that only care about getting that feature added. Our app is a mess, loaded with technical debt and hugely difficult to support and use. 90% of devs dont care, they do add their one piece of new functionality and move on to the next one or next project.
icanhackit 6y ago
> It encourages micro-management. It encourages more and more process. I think it's a case of there being multiple truths, and depending where you sit on the food chain you'll sing one and not the others: 1. If you're a highly competent dev it gets in the way and wastes valuable time 2. If you're a project manager with thousands of moving parts and a diverse array of talent from almost useless to God-tier it can help keep things on track 3. If you're a rookie you can at least quantify and digest which tasks require your attention and not feel overwhelmed 4. By virtue of some common personality flaws you over-estimate how good you are, underestimate what you need to do, and work on the wrong task and still say it's a pile of shit despite it being exactly what you need
jariel 6y ago
'JIRA thinking' is good for bug fixing and resulting issue tracking. It's maybe not so good at the front end of the process.

mnd999 6y ago

100% this. JIRA is bad because it encourages managers to use it to do stupid things, not because it’s inherently bad software.

deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
j45 6y ago
We can say laptops are bad because they let people create bad software too. Jira is far from perfect but there isn’t much that solves what it can in an integrated manner. Sometimes complex problems need complex tools to manage them. Maybe some problems are too simple and basic but imagined to have complexity and end up in an over engineered Jira setup?
- mnd999 6y ago
  Permits and encourages are quite different things though.
  - j45 6y ago
    I'd say less encourages.. And more easily enables. You know the saying that money doesn't change people.. It reveals what already there... Same ca be said to let people make the mess they already probably make. A disciplined workflow in any technology takes effort and thought. I don't feel like I've ever stopped trying to improve it. Sometimes with jira, other times in spite of it.

7thaccount 6y ago

I only used JIRA briefly and it took up way too much time to adequately document our work. I didn't want to leave any work out as I wanted to show all the work being done. Eventually my manager just wanted some very high level stuff absent of any detail and it mostly died out. My new manager just wants a few bullet points once a week on what you've been up to. I feel like I can convey the same information in like 3 minutes instead of using a complicated tool. The advantage is JIRA automatically tracks this stuff for you as opposed to email. I think it mainly caters to micromanagers and allows them to justify additional head count "look at how large our back log is". It doesn't matter that 99% of the backlog isn't very relevant work and hasn't been touched in 2 years for a reason.

polote 6y ago

Any better software to replace it ?

troyintokyo 6y ago
Maybe try with zentao.pm for a scrum tool, self-hosted, open source version available.
contravariant 6y ago
I don't know if better software can replace stupid management but I've been quite happy with Youtrack. That said you can do some extensive micromanagement with that as well, though it requires some coding to do the truly intricate stuff, which just might be enough to prevent the managers from getting any funny ideas ;-)
- keithnz 6y ago
  it's weird why youtrack doesn't come up more often in these types of discussions. It's pretty good, and interestingly enough they now have a "lite" ui mode to simplify it. It's not perfect though, but I've found it hard to find anything better.
d23 6y ago
Napkins and crayons.
deckard1 6y ago
There are literally hundreds of competitors out there. But first you have to describe what you like about it. 10-15 years ago everyone would have used something like Request Tracker (RT). There is Redmine, Pivotal Tracker, Trac, Bugzilla. Those are just a few that I recall using. I've probably used more than that. https://en.wikipedia.org/wiki/Comparison_of_issue-tracking_systems https://en.wikipedia.org/wiki/Comparison_of_issue-tracking_s...

specialist 6y ago

Exactly right. Our folk wisdom metaphors for QA/Test and change management are wrong. Sure, given enough thrust, even pigs can fly. But polish a turd and it's still a turd. [1] JIRAs turrible implementation isn't even as bad as the CRM, ERP, enterprise products of yore. Turrible, sure. But I've seen worse. Much worse. [1] I was a QA Manager for a while. Someday I may publish (explain) the play books my teams used for shrink wrapped releases. (Spoiler: I replaced a lot of heavy weight CRUD based mgmt with lightest weight artifacts. Like just printing all the bugs, taped to the wall, and using approval voting to prioritorize.) Until then, Bryzek's new "testing in production" strategy is the only QA/Test workflow that seems directionally correct in our new agile SaaS world. https://www.infoq.com/podcasts/Michael-Bryzek-testing-in-production/ https://www.infoq.com/podcasts/Michael-Bryzek-testing-in-pro...

devdas 6y ago
That's not a new strategy.

msla 6y ago

I agree, but it will never change. Jira is middle-management-ware, a term I made up (I think) for software that serves the needs of middle management, or, at least, the needs middle management thinks it has, which comes to the same thing as long as you're selling to them. What are those needs? Metrics. Being able to see who's doing what, and how quickly, and what still needs to get done. Being able to make charts and graphs and summarized reports for the next-higher level of management, so they can say that their team is productive and their team isn't falling behind. It also serves the needs of the companies, like Adaptavist, which have attached themselves to Jira to sell add-ons and generally bring the state of the software up to where middle managers (in my experience) think it ought to be out of the box. I could imply that this is deliberate, that Atlassian is Not Adding some features to scratch the backs of those other companies, but That Would Be Wrong, I'm sure.

tootie 6y ago

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 responsible for budgets. If devs aren't working on priority items, are off target to timelines, are not following QA process or not following agreed specs then the company could be losing money. And developers are expensive as hell. And I've also never worked anywhere that had a better option than JIRA.

TheFunkyMonk 6y ago
I'm a developer and I can't remember anything so I love JIRA. I just grab a ticket and have everything I need to work on it.
- SideburnsOfDoom 6y ago
  You are an assembly line robot.
  - kiaulen 6y ago
    This doesn't refute the GP's point though. I've done both the very light management and very heavy Jira, and Jira makes it easy to track what's actually going on. If you want to know what a coworker is doing, you can just check Jira. If you need more work, you don't have to go to strategy and take their time, just look at the backlog.
    - SideburnsOfDoom 6y ago
      > Jira makes it easy to track what's actually going on. No it does not, and I said that above more than once. it makes it easy to track what's in JIRA, that's all. To the extent that it's accurate, it constrains what's "actually going on".

Terretta 6y ago

Have you read David Allen’s Getting Things Done and looked at that system? You have stuff to do today, stuff to do tomorrow, and stuff you might or might not do. Each day you roll the active lists forward. Squint, and it’s just personal Kanban, with TODO and DOING, along with PARKING. These core mechanics work. Where everything goes sideways is when anyone tries to turn those core mechanics into a work breakdown structure fit into a project management iron triangle, per your middle management point. Of course, middle management is just trying to lie to senior management that writing software isn’t invention because invention isn’t predictable — but senior management wants perfect predictability so they know they’re hitting their bonus, by pleasing C-level execs, whose packages depend on pleasing shareholders. Everyone’s building a Jenga tower of predictably hitting the numbers. So if you don’t like JIRA, blame shareholders. :-)

Closi 6y ago
One size fits all never works in reality. Jira / Kanban works for some projects while Waterfall works for others. Some projects need high levels of governance while others move faster with low levels of governance. Some projects can get away without time-commitments, but others have dependencies and must hit deadlines, and this must be tracked. And just because GTD is great for managing my personal workload, doesn't mean that it's great at coordinating the work of 100 people. (I say this as a person that generally believes in Agile, is a huge proponent of GTD, and have also been on a dev team where Agile and Kanban was applied where traditional Prince2 would have been a better fit).
benzible 6y ago
I agree with your larger point but pointing to GTD as evidence that the "core mechanics" work is questionable. Many of its biggest advocates have abandoned it. > Just as G.T.D. was achieving widespread popularity, however, Mann’s zeal for his own practice began to fade. [...] Productivity pr0n, he suggested, was becoming a bewildering, complexifying end in itself—list-making as a “cargo cult,” system-tweaking as an addiction. “On more than a few days, I wondered what, precisely, I was trying to accomplish,” he wrote. [...] It seemed to him that it was possible to implement many G.T.D.-inflected life hacks without feeling “more competent, stable, and alive.” [1] https://www.newyorker.com/tech/annals-of-technology/the-rise-and-fall-of-getting-things-done https://www.newyorker.com/tech/annals-of-technology/the-rise... (or https://beta.trimread.com/articles/59839 https://beta.trimread.com/articles/59839)

kjd1231 6y ago

What bothers me is if I use JIRA, why do I have a meeting every single day telling you what I'm working on. If you care, look at JIRA.

joegahona 6y ago
To discuss blockers and what you'll be working on that day. Also many engineers aren't good about updating tickets, ruining it for everyone.
- kjd1231 6y ago
  I plan on working on the tickets assigned to me on that day, yesterday, and the next day. If I have blockers I'll type up a slack message. It's not that hard.
  - deleted 6y ago
    [deleted]
- Andys 6y ago
  In some cases, maybe they would be better at tickets if not forced to use JIRA.
  - joegahona 6y ago
    Yeah, no arguments from me. I'd rather watch someone read a book than use Jira.
- timka 6y ago
  That's the problem. You have to actually use Jira to get any value out of it. And better use it properly. That is do it accordingly with your process or the lack of it.

ogre_codes 6y ago

> Fixing a bug without filing a JIRA ticket is in itself progress. When I see comments like this I have to wonder if you've ever worked on a team with more than one person on it. Without some kind of ticketing system—JIRA, Pivotal, heck Trello—How do you know a bug is getting worked on? How do you even know which bugs are a priority? Are the designs complete for the next feature I'm building? How does QA know to review your changes? (Yes QA is still a thing in some places and for good reason) When I was a solo dev, I would meet with the rest of the stakeholders weekly and establish what I was working on. But on a bigger team this quickly becomes impractical. Even with the 8 person team I work on now I'd have no idea who was working on what without having some kind of tracking system.

Closi 6y ago
I assume one of the use-cases for this is that they found a bug, quickly fixed and wrote a test case, and then pushed it to Git without raising a ticket themselves and then solving the ticket. With an 8 person team all sitting together, someone can just shout across the table and ask someone else to resolve an issue without raising a ticket too. Are you solving ticket A but need another person to help you with a bug you discovered in the API that the person across from you wrote and can fix in 2 mins? Sometimes they just do it and don't raise a ticket. If management likes to mark you on tickets, you might as well raise the ticket. I work at a big company, and every time the IT Helpdesk does a password reset they open a ticket, then mark it as closed, every time they do a password reset (because they get marked on how quickly they close tickets). Believe it or not, median resolution time for a raised support ticket is in seconds, despite it usually taking days if you open a ticket for anything yourself! 8 person teams are usually the recommended max team size anyway under Agile (two pizza team).
- ogre_codes 6y ago
  > someone can just shout across the table and ask someone else to resolve an issue without raising a ticket too. I rarely see my team-mates in person at the moment to shout at them. If I did, they would likely tell me to fuck off because they are busy with some other task. The only sort of issues where it's appropriate to drop what you are doing and immediately fix it are the most severe issues which need to be fixed right now. > I work at a big company, and every time the IT Helpdesk does a password reset they open a ticket, then mark it as closed, every time they do a password reset (because they get marked on how quickly they close tickets). In general, if documenting an issue (of any sort) is more work than resolving the issue, you shouldn't bother documenting it. But as a developer, many of those easy to fix issues are found by people who don't have the skills or resources to fix them. The best way for someone to communicate those problems is usually some kind of ticketing system.

LanceH 6y ago

I just had this discussion this week. I'm doing work in Jira to build metrics, rather than metrics being tracked from what naturally occurs in Jira. While I understand that most of these problems come from the setup and the decision to use Jira a certain way, I feel the system itself encourages busy work. As a developer, I've felt the Fogbugz way of doing this most closely mapped to my natural workflow. It is also built around the concept of a single person "owning" a ticket, providing a natural flow from person to person through the lifecycle of a ticket. This can be done in Jira, of course, but it is a mental drain as it requires more bookkeeping. edit: I guess what I'm saying is that Fogbugz in particular is a bit more opinionated and lines up with what I think is good. Jira naturally guides management to all sorts of extra crap.

_5yoy 6y ago

Every single job I've worked that used Jira, also used google sheets to "map" actual work to Jira work. It has always blown my mind. All the meetings to update the google sheet, and then to update Jira, and then to ask why the two aren't in sync. It feels like I'm taking crazy pills. Why are we using a manual tool (google sheet) to keep track of the work, that's in our work tracking technology? What?

redisman 6y ago
Because there’s so much friction to do anything in Jira. It’s horrible for any kind of planning or really anything that’s not set in stone. I just keep a text editor with my current and next tasks and then update jira at the end of day based on it.

blinktag 6y ago

Agree 100%. JIRA is supposed to be a means, not an end itself. Half of my organization believes they are generating value by adding new issues into JIRA. JIRA helps reinforce a dogmatic attitude that the "hows" are more important than the "whys", and thus issues that could be succinctly described in 20 words get expanded into templated "given/when/then" verbiage. One of the core Agile principles is "individuals and interactions over processes and tools". JIRA is more-or-less value neutral, but the management caste, possibly fearful of the sort of healthy conflict that comes with negotiating the priority of features and fixes, tends to resort to inputing all their information into JIRA believing that it's a substitute for actual communication. Every Agile resource I've read has emphasized the point that nothing is equal to actual conversation between stakeholders. Whether it's JIRA or one of its competitors, when you have a tool that discourages conversations or pretends to act as a proxy for collaboration between stakeholders, you're going to court failure. Easy to blame JIRA, but it's this whole tool-based mindset.

tpmx 6y ago

We used to call that anti-pattern "playing Jira Tetris" at a previous workplace. It's excellent at the creating the illusion of productivity. Some people really fall into the trap deep.

deleted 6y ago

[deleted]

wpietri 6y ago

Exactly. Computers having infinite capacity is sometimes harmful. One of the things I like best about kanban approaches, especially with physical cards is that they discourage putting in too much. When I look back on previous boards (e.g., [1]), my main thought is we still had too much room. We wrote up and carried along so many cards we never got to. But even so, that's way better than something like Jira, because the limited board meant limited opportunity to distract ourselves with meta-work. [1] https://williampietri.com/writing/2015/the-big-board/ https://williampietri.com/writing/2015/the-big-board/

rasengan0 6y ago

What really sucks is the cheeryleading and evangelism for it almost like a cult by the very people who are not responsible for resolving issues. Side channeling by email/phone with expenditure of social capital to devs in the know is quicker with our mutual wink wink agreement to file and close the Jira ticket to appease the higher ups above. Absolutely ludicrous.

musicale 6y ago

Jira is not completely useless: it gives people who usually add negative value to the project a way to appear busy and productive, with associated rewards and promotion opportunities.

Sodman 6y ago

The biggest problem with Jira, is that they give you the gun and the bullets to shoot yourself in the foot, while trusting you not to do it... The reality is that most teams (or let's be real, managers) can't be trusted not to shoot themselves in the foot here. Adding more features and more process in general is going to be a net negative for developer productivity. But how well Jira (or similar tools) works for you is completely up to how you use it. Most teams I've seen that hate Jira et al usually have an overly complicated process, with far too many "states" for a ticket, a million mandatory fields, multiple assignees, etc. This naturally results in people spending far more time in the tool, which is time they could be spending actually doing productive work. Conversely, teams that like Jira tend to have very few ticket statuses/fields. Standups are quick, sprint planning is quick, everyone wins. Unless your job was moving things around in Jira for 20+ hours / week... in which case you'll need to find something else to do.

deleted 6y ago

[deleted]

bww 6y ago

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 probably going to have a difficult time if you can't reconcile yourself to the utility of this sort of process.

jiggawatts 6y ago
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.

aard 6y ago

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.

eddieh 6y ago
The irony is that I always had my own task list that I kept in parallel to Jira that allowed me to break a Jira issue down into subtasks, subsubtasks, down to any depth of n(sub)-tasks. The best part was that there was no "process" for my task list. It was always just TODO and DONE. Nobody had to review my list or approve it and I could delete and add entries as needed with zero friction.

jayd16 6y ago

>it is a LARP of the work This is the major problem I see. Just like misleading code comments pollute a code base, bad tickets and fantasy tasks pollute any useful information you might get from a ticket older than a couple weeks. If we're really being agile "moving something to the backlog" would just delete the ticket. If its important enough, you'll write it up again.

catears 6y ago

I work in the med-tech industry and Jira is a very good fit for that industry. Most compliance issues are solved by defining a way of working that uses a project management system like Jira. Someone else read how to label a product with CE-label and HIIPA, and all I have to do is report my work in Jira. Don't have to understand CE-labeling or HIIPA. For compliance it must be possible to find who made a change, why they made that change, and how they validated and tested that change. In a heavily regulated industry like medical, it is very useful to have a tool like Jira when the audit comes up. I still accept your point tough, if you need to go fast and break things (you know, innovate and prototype things), jira is a real blocker and the "jira mentality" slows things down, for better or worse.

x87678r 6y ago

Its Jira combined with outsourced or contract developers that only care about getting that feature added. Our app is a mess, loaded with technical debt and hugely difficult to support and use. 90% of devs dont care, they do add their one piece of new functionality and move on to the next one or next project.

icanhackit 6y ago

> It encourages micro-management. It encourages more and more process. I think it's a case of there being multiple truths, and depending where you sit on the food chain you'll sing one and not the others: 1. If you're a highly competent dev it gets in the way and wastes valuable time 2. If you're a project manager with thousands of moving parts and a diverse array of talent from almost useless to God-tier it can help keep things on track 3. If you're a rookie you can at least quantify and digest which tasks require your attention and not feel overwhelmed 4. By virtue of some common personality flaws you over-estimate how good you are, underestimate what you need to do, and work on the wrong task and still say it's a pile of shit despite it being exactly what you need

jariel 6y ago

'JIRA thinking' is good for bug fixing and resulting issue tracking. It's maybe not so good at the front end of the process.