It’s a sign of how bad JIRA is.
The tool is so bad that people (including me) want the integrations to be hard simply to have a reason not to use it.
The tool is so bad that people (including me) want the integrations to be hard simply to have a reason not to use it.
You obviously don’t believe that you have a choice in the matter today. But you also seem to have a helpless belief that you won’t have a choice in the matter tomorrow, nor do you seem to believe there are things you can do to have a choice tomorrow.
So instead, you are wishing that something else would force the universe to give you what you want, but without you actually changing your circumstances such that you can freely choose not to use JIRA tomorrow.
I urge you to shift your thinking and make it your business to recognize that you actually do have a choice today. You can work somewhere else. That has some costs you may not care for, but it’s healthy to say, “Overall, I like the choice I’m making” and then to be happy with the outcome.
Next, I urge you to believe that you can make choices today that give you even greater freedom to choose not to use Jira tomorrow without making difficult tradeoffs.
When you have greater confidence in your own freedom of choice in these matters, you will be happier today and tomorrow, and you will let go of wishing that other forces will act to give you what you want in life.
Summary: Working on your own agency is far, far better for you personally than hoping that the universe will conspire to make other people stop choosing to ask you to use Jira.
So I understand the frustration when someone from the engineering side builds something for it -- "why, oh god why are you trying to extend its life?!?"
If Jira didn’t exist, someone would build it, because said managers have the budget and authority to spend.
If we want a different management culture, we have to work on the culture directly. Which is the entire point of agile, lean, and other movements.
As for managers buying it and imposing it on their engineers, we need to recognize that said managers are users too, and their needs matter. It’s not like there’s a good tool and a shitty tool, and the engineers and managers put in a requisition for the good tool, but the CFO plays golf with the shitty tool’s VP of Sales and they buy the shitty tool.
Managers want Jira for a reason. We may not like the reason, but that doesn’t mean they’re wrong, and it especially doesn’t mean that if we burned Jira down to the ground its replacement wouldn’t address the reasons managers want Jira.
If we believe that software can do what managers and engineers need doing without being as craptastic as Jira, we need to build it.
But we can’t ignore what managers need. We either give them something else that solves their problem, or we stop worrying about Jira and get them to approach software development in a new way.
JIRA can be a decent tool. The issue is the way that 90% of all businesses big and small use it, is just so that managers can shrug off any responsibility for understanding the projects they're managing, and wall themselves off in JIRA bureaucracy.
Engineers have not taken too kindly to it.
Project Manager types dont mind JIRA slowness for some reason. Prbly have too much time in their meetings to sit and wait around.
- made JIRA look fast
- only ran in IE6
- required a special MSIE shell to run in Win7
- despite running only in IE6/Windows, it had several places where it broke from the standard Windows UX
On the other hand JIRA UX and moreso Atlassian UX needs a lot of work. A number of common things take wayyyy too many clicks. It’s hard to discover etc. A good integration can definitely fix that mess.
GitHub knows how to do good simple UX.
.
.
.
.
forever
- conflating how you interact with issues (bugs, security events, new client on-boarding, etc) and how you do product development (prospecting, requirements analysis, systems design, etc). These activities only have a passing relationship with each other. Designing new products is fundamentally different than dealing with customer service items. Just as a specific, issues in JIRA are a terrible way to capture the vision and mission of a new feature. They are further a terrible way to capture requirements which in any other system would be versioned along with the software they define.
- the customization of workflows encourages teams to think of every component as a fungible unit. If you don't define 'workflows' and instead prioritize around results, you can motivate teams to operate in their best ways. If you build complicated or bespoke workflows in JIRA you operate in a way that presumes that all teams and all situations can be put in the same box.
- JIRA, especially in its most customized versions, implies that you can replace normal human communications, conversations, emails, chats, with a Platonic ideal of tickets. Yet tickets are a bad mechanism for spreading big picture ideals and an even worse mechanism for spreading specific details of a functional specification (no testability, no atomicity with software change, etc).
- JIRA's customizability leads people to think that the right thing to do with their project management teams is to define standardized workflows, automated integrations, normalized schemas for issues, and the like. Instead of doing the hard work of aligning priorities Project Managers get caught up in the minutia of making sure tickets are in the proper form or that developers have moved tickets through the correct statuses.
All told, this is one of those cases where worse is better. A title, a comment box and a set of tags largely allow you to systematically capture everything you need to capture and allow a qualified project manager to do their job. Github issues does this, JIRA out of the box does this, Bugzilla and FogBugz all do this. I only ever run into problems with JIRA, so I can only extrapolate from experience that it is something about JIRA that leads Project Managers to spend less time with legal pads and more times futzing with JIRA.
Jira gets the flac, because but the problems isn't Jira.
I recently had somebody come up and tell me: "I can't get a grasp of the status of the sprint because of Jira."
The issue, in stead was that people were creating epics all over the place and nobody ever updated their stories. So there was no clear structure and the burndown never burned down. I've worked with Jira for a long time and I can, almost, always adapt it to fit a process. However, when nobody knows that the process is, it's impossible to create a good version in Jira, but Jira ends up getting the blame.
JIRA is a software product but also a social institution, an organizational philosophy. Sure, you can have the software without the attitude or vice versa, but use of JIRA is still a (weak) negative signal about the quality of an employer.
Turns out that the main thing protecting employee autonomy is the logistical difficulty of micromanagement. JIRA "solves" that problem.
JIRA is successful because it is a good tool that gives power to the users. Anyone is free to build a competitor to JIRA, but I would argue that if the developer limits it and forces the client to use their preferred process methodology that they will likely fail.
Just my opinion. I have only been using JIRA for a few weeks now, have had no issues. Nothing amazing about it and nothing terrible. It does the job. Its just a tool. How its used is up to the user.
Of course you can use JIRA as just a tool, but it tends to take on a life of its own, becoming central to his work is allocated and performance is assessed.
A lotta folks I talk to have had bad experiences with Jira in a big-company setting -- say in particular, Amazon --- but most of those problems I've heard boil down to poor practices on the management / admin end, rather than problems with the software itself.
p.s. I've also used Asana and a few other less-costly solutions, but their limitations ended up getting frustrating.
It has a fair share of issues (it's SO SLOW to do just about everything, and the text editor annoys me to no end!), but overall I think it's making me more productive and it's a lot easier to keep track of what i'm doing, what i've done, and what still needs to be done.
Jira is a crutch, in the most literal sense: it makes things that should be hard because of your lack of {personal, organizational} health, easy, in a way that makes people avoid doing the "healthy" thing (facing their problems and rebuilding said {personal, organizational} health) indefinitely.
Would you spend any time trying to solve the problem in the system?
Don't the simpler (more opinionated) systems also tout the same?
All software is sold with the same promise in one way or another.
However JIRA Agile is a dumpster fire, partly because JIRA Agile reinvents JIRA.
Summary field? Yes, but also "Epic Name" field.
Status field? Yes, but also "Epic Status" field.
Priority field? Yes, but also "Rank" field.
Subissues? Yes, but also "Epic Link" field.
And then boards and sprints are weird. Boards are supposed to be just views, but then access permissions for closing sprints depends on the view you were looking at when you created it.
Plus the UI bad; the whole board gets really squished and becomes essentially unusable if I half-screen it.
Different parts of the UI and some functionality works differently for subtasks than for linked issues.
For example, you can set it up so that you can't close a 'user story' until all subtasks under it have been closed. Not possible out of the box with linked issues.
I'm not expecting much. For one this is a space that many engineers sneer at ("product/sales/marketing/not-engineering" is beneath them) and don't really want to work in. Another thing is that many of the individuals responsible for deciding on project management tools are not qualified to do so but think they are and won't apply effort to doing a proper job of evaluating options.