Several years back, before Jira became the software everyone loves to hate, I worked at a smallish company where the engineers had brought up local Jira instanc

Several years back, before Jira became the software everyone loves to hate, I worked at a smallish company where the engineers had brought up local Jira instance as a sort of skunkworks project, because the bug-tracking tool the company had been using wasn't working for them. They set it up to fulfill the basic need for programmers on a team to keep track of their work. Fast forward a couple of years and it had become the company standard, replacing whatever preceded it, and the company had at least doubled in number of employees. The Jira workflows and ticket fields got the "corporate standard" makeover, including adding a field with so many values that alone it accounted for much of the increasingly poor performance. The arguments the author makes here encapsulate the evolution at my then-employer. Everything became about using an enforced process and workflow. The worst part about it was how some of the changes were enforced on all projects from the top down, meaning teams (like mine) that had a reasonably good, workable project setup had to change the way we did things, use different terms, and generally give up the working style that made use successful. Some time later, much to my chagrin, I ended up consulting at a company using something even worse than Jira: + Azure DevOps, Azure Boards, and all things Azure. These were coupled with the micromanagement and non-manager anti-patterns described in this article into a situation where developers spent more time pushing buttons and shuffling tickets arounds than writing code. The engineering manager made it clear how, to her, seeing tickets moving through the workflow on the board, on schedule was as important as working code.