I actually ask during interviews if a company uses any type of Agile/Scrum/Kanban/"sprint cycle" workflow or uses JIRA/Asana/other Agile-focused metric trackers -- and immediately reject doing any more rounds of interviews with that company if they do. I'd say about 80% or so of the companies I speak to get rejected immediately just for this reason alone.

I've found that this is one of the very best indications that a given company has dysfunctional management, doesn't prioritize engineering quality or craftsmanship, views software labor as a cost center of the business instead of a value center, and views programmers as easily replaceable commodity workers.

I totally grant that it's possible I am passing on some good companies when I do this. But the false negative rate has to be extremely low, since so many other companies with these tools have repeatedly demonstrated themselves to be horribly managed, talent-wasting career killers. I'm happy to suffer the false negative rate just to be super safe that I don't end up in another such place in my career. And to boot, even though I've turned down follow-up interviews with many places because of this, I've never regretted doing so, and have often learned after the fact that there was significant engineering dysfunction in that firm from other sources.

I would really love it if either DeMarco & Lister (who wrote Peopleware) or Jackall (who wrote Moral Mazes) would add new sections to their books specifically about the invalidity of Agile-like management techniques, and the way they are used for 'dexterity with symbols' (as Jackall puts it in Moral Mazes) to create political arguments for micromanagement and keep developers distracted, while devaluing their labor and disconnecting the field from the spirit of craftsmanship.

> But the false negative rate has to be extremely low

How would you know, you reject them offhand.

Thankfully, that sounds win/win.

In some cases, I have known other people who worked in the companies and attested to the poorness of the work environment, or been able to read large and very public accounts of employee discontent within them.

Another good indicator of the same things is the unnecessary use of open-plan offices, especially if combined with a lack of willingness to permit significant time working from home.

Right and as it says in the title, use of JIRA is often a symptom that there is a problem with management. Nowhere is it stated that JIRA itself is the problem.

So the title should've been 'the use of an issue tracker is a symptom of a management problem'. But that title is absurd, hence the click bait title.

I disagree. JIRA goes further out of its way to accomodate Agile/Scrum stuff than many other issue trackers. I was on a team once where we used FogBugz (without any of the metric tracking nonsense -- our managers didn't even log in to it, they just talked to us when they needed to know about progress) for a long time without any issue, and only after some big middle management restructuring did we switch to JIRA, specifically because managers wanted a tool that spit out useless junk about velocity and burndown. We even had to go and do really dumb training about "story points" and how to enter the progress data they wanted (which added so much overhead to entering things into the system that most of us just stopped, or at least cut every possible corner so as to not waste our time doing manual data entry for the sake of middle management).

Not every such tool focuses on these kind of pointless metrics so much. Using the GitHub issue tracker is joyful, especially when you don't have someone trying to micromanage you with it. Some tools focus instead on what the actual developers need to get their work done, instead of what managers want in order to be more micromanagerial.

Another tool that is starting to go down the dark path of JIRA is Asana, which is a shame because the original design of Asana was great. But now it's all about Scrum metric bullshit, catered to middle managers who have the power to choose it over other things, and usually don't make the choice based on developer preferences or rational arguments.

I'd say the title could be "Agile/Scrum metric trackers are a symptom of a management problem" and that JIRA is absolutely the poster child for such a tool, so it's not bad faith to tie it directly to JIRA. Though your point does bear repeating: JIRA is not the only tool that suffers from this problem.

It is "failure to use issue tracker effectively" and it happens all the time.

The problem is confounded by many little cuts. For instance, they think that the issue tracking system is only used by devs, so it goes on a dust-filled desktop machine from '03 that is stuffed in a corner somewhere, so it is underpowered and takes 25 seconds to load a page over my DSL connection and about 22 seconds at the office.

The people at the office don't care, however, because the boss thinks the issue tracking system is a waste of time. He bitches me out for taking 10 minutes to write up an estimate and then giving an estimate which is always "too long." I am carefully watching the star programmer to understand what he does right, and finally realize the reason he doesn't have this problem is that he doesn't estimate anything. Sometimes the testers put in tickets, and sometimes the star programmer puts one in, but the "product owner" never puts one in or bothers to show up at the scrum meetings down the hall.

Top management assigned a project manager to our team and she was putting in the scrum thing because my team had been going in circles for two years and they had to get a product in front of the customer. My boss pushed her out and she left to work for some kind of Christian charity.

At some point our boss got the religion of checklists, gave up on the idea of estimating or scheduling, and somehow we got it across the finish line.

But you can't say the same about every issue tracker. For example, GitHub Issues is so constrained that it's difficult for management to bend it, for good or ill.

The title has been edited to include to word "Often"