4 ms·

Excellently written. As I have said before on this site, Jira is the wet dream of mediocre middle-level managers who feel the need to micro-manage by ticket, r

by gjvc 5y ago

Excellently written. As I have said before on this site, Jira is the wet dream of mediocre middle-level managers who feel the need to micro-manage by ticket, rather than lead by example. Jeffries makes the point that the symptom of this malaise is that the primary system of measurement is "what's in Jira" rather than what the product is becoming.

kevincox 5y ago
A great example I see towards this is Jira's strict hierarchy. My middle-management creates Epics and some Tasks for me (and subtasks are forbidden because apparently they are buggy). But if those are big enough to need their own work I can't divide further to keep myself organized. It assumes that whoever created the ticket knows roughly how much work it is or you need to go back and negotiate the structure, and ruin a bunch of links. For me personally I want to track things that need to be done, not "week sized" bits of work or whatever your team is calling "agile".
- gjvc 5y ago
  > subtasks are forbidden because apparently they are buggy heh, I've experienced exactly this. Makes a mockery of the whole setup.
  - ansgri 5y ago
    Good to see our dislike of them validated, too. They don’t work well with sprints.
    - gjvc 5y ago
      It's not validation, and your dislike is misplaced in the context of kevincox's comment: "But if those are big enough to need their own work I can't divide further to keep myself organized", where they are very much needed to track the work which needs to be done. The emergent behaviour of a jira installation seems to be one which more often serves management-by-ticket, not the "task progress" aspect of a lab notebook. GeePaw Hill's tweet is soberingly true https://twitter.com/geepawhill/status/1448667876907524108 https://twitter.com/geepawhill/status/1448667876907524108
      - ansgri 5y ago
        We worked around them by basically not using epics (using them to represent an endless line of work like Frontend, or Machine learning, the like), but instead introducing a new type of issue, Sprint goal, which is created by the team leads committee and linked to actual tasks as related issues by individual developers. So we have both ‘big picture’ for current work and not interfere with developers. The sprint goals serve to record current priorities agreed between teams and CTO, are 2 week-scoped (hopefully), and reviewed at the end of the sprint. Seems to work well for our ~50-developer department. edit: To add, overall Jira+Confluence is more pleasant to work with than Redmine and Basecamp, though it does require a big team with a couple part-time Jira experts to make it work.
    - kevincox 5y ago
      > They don’t work well with sprints I think that was the "bug" in my context.
      - gjvc 5y ago
        now I'm confused as all hell, and I apologise for any offense caused.
  - dzhiurgis 5y ago
    Takes like 4 screens to reparent a task. What a load of garbage. Makes me wanna quit after years of work, just because we switched to Jira.
- malermeister 5y ago
  I usually have a few decoy jira tickets to keep management happy and then do my own task tracking for myself using tools that don't suck.
- theamk 5y ago
  Does it really matter if it is a Task or Subtask? I think that kind of focus on the words is why people start hating Jira instead of trying to fix what matters. JIRA is a bug tracker -- it has "summary", "description", "assignee", "status", and "a bunch of fields only management cares about". So deal with it as you'd deal with any other buggy software. If subtasks cannot be used, make a bunch of new tasks and set it as a blocker of the "final" task. If setting blockers is buggy, start putting comments in the title ("Big task [1/3]: Refactor foo", "Big task [2/3]: Add bar to foo"). Now, perhaps the real problem is then you are not allowed to add/change the tickets at all, only middle management can? It is a huge problem indeed, and I fully agree that this can ruin your life. But this is not JIRA's problem -- your management could do the same thing even you have switched to sticky notes attached to your wall.

by gjvc 5y ago

kevincox 5y ago

A great example I see towards this is Jira's strict hierarchy. My middle-management creates Epics and some Tasks for me (and subtasks are forbidden because apparently they are buggy). But if those are big enough to need their own work I can't divide further to keep myself organized. It assumes that whoever created the ticket knows roughly how much work it is or you need to go back and negotiate the structure, and ruin a bunch of links. For me personally I want to track things that need to be done, not "week sized" bits of work or whatever your team is calling "agile".

gjvc 5y ago
> subtasks are forbidden because apparently they are buggy heh, I've experienced exactly this. Makes a mockery of the whole setup.
- ansgri 5y ago
  Good to see our dislike of them validated, too. They don’t work well with sprints.
  - gjvc 5y ago
    It's not validation, and your dislike is misplaced in the context of kevincox's comment: "But if those are big enough to need their own work I can't divide further to keep myself organized", where they are very much needed to track the work which needs to be done. The emergent behaviour of a jira installation seems to be one which more often serves management-by-ticket, not the "task progress" aspect of a lab notebook. GeePaw Hill's tweet is soberingly true https://twitter.com/geepawhill/status/1448667876907524108 https://twitter.com/geepawhill/status/1448667876907524108
    - ansgri 5y ago
      We worked around them by basically not using epics (using them to represent an endless line of work like Frontend, or Machine learning, the like), but instead introducing a new type of issue, Sprint goal, which is created by the team leads committee and linked to actual tasks as related issues by individual developers. So we have both ‘big picture’ for current work and not interfere with developers. The sprint goals serve to record current priorities agreed between teams and CTO, are 2 week-scoped (hopefully), and reviewed at the end of the sprint. Seems to work well for our ~50-developer department. edit: To add, overall Jira+Confluence is more pleasant to work with than Redmine and Basecamp, though it does require a big team with a couple part-time Jira experts to make it work.
  - kevincox 5y ago
    > They don’t work well with sprints I think that was the "bug" in my context.
    - gjvc 5y ago
      now I'm confused as all hell, and I apologise for any offense caused.
- dzhiurgis 5y ago
  Takes like 4 screens to reparent a task. What a load of garbage. Makes me wanna quit after years of work, just because we switched to Jira.
malermeister 5y ago
I usually have a few decoy jira tickets to keep management happy and then do my own task tracking for myself using tools that don't suck.
theamk 5y ago
Does it really matter if it is a Task or Subtask? I think that kind of focus on the words is why people start hating Jira instead of trying to fix what matters. JIRA is a bug tracker -- it has "summary", "description", "assignee", "status", and "a bunch of fields only management cares about". So deal with it as you'd deal with any other buggy software. If subtasks cannot be used, make a bunch of new tasks and set it as a blocker of the "final" task. If setting blockers is buggy, start putting comments in the title ("Big task [1/3]: Refactor foo", "Big task [2/3]: Add bar to foo"). Now, perhaps the real problem is then you are not allowed to add/change the tickets at all, only middle management can? It is a huge problem indeed, and I fully agree that this can ruin your life. But this is not JIRA's problem -- your management could do the same thing even you have switched to sticky notes attached to your wall.