That sounds more like a disastrous missing feature to me.
A good productivity tool doesn’t dictate how teams work.
I’d rather have a tool that’s more customizable.
A good productivity tool doesn’t dictate how teams work.
I’d rather have a tool that’s more customizable.
It simply slows everyone down, but when it's your only tool for tracking work, it's still better than nothing.
Now, the problem with Jira is not necessarily customizability but that it's dog slow, complex, integrations suck, and permissions system is chaotic. Still, I have yet to see fully customizable work tracking system that's better made than Jira.
But also, a fixed set of features does not force you to ascribe the same meaning to them like the authors intended: I've used "bug" tracking systems to manage large projects with great success (including big features, enhancements, but also big and small fixes).
Project management software isn’t made for the benefit of engineers, that’s on purpose. The customer is the business, not the engineer who works there.
Any issues with the engineers have with workflow really aren’t the fault of the software, it’s the fault of the project managers/engineering managers’ configurations.
You can’t blame the company that makes the paint for the choice in paint color.
Personally I think the only way Jira has dropped the ball is on page load performance.
I've seen many custom JIRA workflows, where you define specific states that can progress to other states. Nearly all of them, over time, were modified so that any state can move to any other state.
And if you engineers don't use the tool you provide, the data in it is useless. Engineers are typically very smart and will just twist any tool they don't like.
Declaration: In order to have accurate state between projects and bugs, everything needs to be tracked in JIRA.
Result: 70% of your Jira stories are now "This JIRA tracks an issue stored in the Github repo, see the repo for current status"
When I create a ticket and don't open it right away before the popup is gone, poof, it's gone into the depths of that project backlog.
If I want to create a multi-project board, oh, now tickets don't have the same statuses, set up a mapping first.
Or figuring out the artifical limits between epics, tickets and subtasks.
And slowness, don't get me started there.
Yes, just like you are blaming the paint shop for only having the basic colors, I too can blame the paint shop for having 1M green hues to choose from.
You think you would, until you do, and by then it's too late.
It's important to have good processes, but the point of all those processes is to help you make things more efficiently. Anything that leads to you spending extra time serving the process directly reduces the amount of real work you can do.
I think this viewpoint -- that these processes somehow could increase efficiency if only they were good -- has a lot to do with why engineers dislike systems like Jira, because they will never see the increased efficiency they are looking for.
Let me restate it in a way that I think is a little more nuanced:
The point of systems/processes is to lessen the amount of inefficiency in a group of people working together as that group a) gets larger, and b) experiences turnover.
Nothing's ever going to be as efficient as a single engineer that can build everything with all the details in their head at that very moment. But there's a limitation on size of problems you can solve doing that! So many people working on large problems hate their processes, because each individual person is doing less than if they were in a tiny, stable team, and they can feel this, even if the organization is making great progress.
(And then, at the largest sizes of organization, it's almost impossible to stop the org from crumbling from the weight of its own complexity. People do spend an awful lot of effort trying, though).
But, I've also worked in shops so hidebound that the aim of the organization seemed to be to Follow The Process above all else. Didn't ship anything all quarter? Well, at least we Followed The Process! Customers are screaming? That sucks, but The Process doesn't accommodate their needs this quarter. Principal engineers are leaving? They just don't appreciate The Process!
In my experience, Jira seems to resonate with PMs who adore The Process for the sake of The Process. Lighter, more opinionated systems like Pivotal or Linear seem to help teams deliver features more quickly than teams using Jira to march in line with The Process.