The use of JIRA is (often) a symptom of a Management problem

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.

The major problem with that is we are incredibly good at gaming the system. I've seen mediocre, at best, team became a glowing beacon under the velocity game; they managed to close 2000+ stories in one year! (a developer closed well over 1 story per day on average).

Software estimation is a really hard problem. We can attempt to establish order by pretending that burning down/velocity charts actually say something useful. How do they work when all the methods we know fail? No idea. But have faith, because we have plenty of anecdotes of its success!

To be fair, you have to accept that Taylorist doctrine states very emphatically that analysis, synthesis, logic and rationality are the exclusive domain of management. Boss's responsibility is to think very thoroughly about how work is to be done, and worker's responsibility is to do exactly as told. In Taylor's work it goes as far as to dictate how ofter and for how long workers are to take breaks (so the maximum amount of labor can be extracted from them without exhausting their muscles before the end of the shift).

To complete your list, empiricism and work ethic are the tactics that are to be used to apply all that management's brain power; efficiency and elimination of waste are the end results; and standardization and best practices are the institutionalization of those end results so that the manager's enlightened intelligence can move on to "fine tune" the next process in the assembly line.

I am not saying that there is no use of standards and best practices. If anything, in the software industry we need to be more strict, not less, about the best practices we already know and have known for several decades. But there is a big difference between that and the kind of micromanagement that this kind of tools elicit in practice.

i.e. Professional athletes do need to drill until individual movements become second nature, and proper technique matters a lot if you are competing at the highest levels. But you do not see coaches trying to dictate what each player will do on every conceivable situation. Even in extremely structured sports, like football, the coach dictate a general strategy and changes tactics according to the dynamics of the game, but each individual player needs to apply a minimum of discretionary judgment to react to situations that arise mid-play.

A coach that tried to move his players like puppets would be crushed by the competition. An army with such general and soldiers would be crushed in a more literal way. Why is it not the case with software companies?