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.

I've had 3 jobs where we used Jira and it was always a nightmare. At Uber ATG it sucked because it was slow, extremely confusing, managers didn't know how to use it, engineers didn't either, it wasn't integrated into any developer tooling, and there was no dedicated Jira engineer so it just slowly wasted away. At Amazon, same story as Uber ATG, but we had a dedicated engineer, yet somehow it was still slow. At this startup called Attensity, it was the exact same story as Uber.

I've seen Jira work for other things that aren't software engineering related, where it seems like tolerances for crappy software are higher. We use Jira for creating tickets for new computers or requesting access to certain recourses. Those things are fine because they aren't really sprint related — it's more like a fancy to-do system with time stamps. However, if you're on the building and landing software train — nobody want's to hear the word Jira.

The issues I find (including speed) are really due to the incredibly flexibility of Jira, and things not being thought out by users. Ultimately, I feel like it's akin to the old adage about perl - it does everything including giving you the rope to hang yourself.. it's up to you if you hang yourself. That plus all my friends who insist one needs a PhD in Jira, to Jira... but I digress.

We're set up appropriately with issue types, differentiation between issues, bugs, tasks, (and our version of etc). We can plan sprints locally and remotely, and have all our dashboards and friends immediately update. Integrated (sanely) with confluence we get retrospectives, historic reports. We create bugs, move their states, deal with Agile and Kanban, have histories... the whole deal. To reduce the inherent pain in dealing with bug creation because it generally sucks, we have a slack integration I wrote to: a. Create a bug b. When you type ISSUE-ISSUE# into a channel, the robot picks up and gives us all the subject.

The combination above removed all friction. The one thing I wish would happen from a workload perspective is that when a PR is pushed upstream to bitbucket, for a branch matching an issue - the issue would move to the Code Review state. But that is our only point of friction, and one day I'll get off my rear and make our robot do it.

[0] - https://confluence.atlassian.com/bitbucketserver/using-smart...

I always took care of our workflow and small issues by the side. Once configured properly (which has nothing do to with magic) it works as advertised.

there are a few small issues but not that relevant in daily life.

We used atlassian online service and on premise.

I worked with jira and scrump but the last two years I introduced kanban. But those projects have a high level of uncertainty and supportrequests. Which just makes it hard to finish a Sprint.

Always git. Git with GitHub.com, on premise GitHub and selfhosted gitlab.

I do use the reporting Features. It is nice to see the progress. Seeing the backlog shrinking and also the time on how long a ticket is in progress. It helps a little bit of keeping priorities. It also helps showing the management why stuff takes as long as it takes. Especially unplanned work.

It makes management's job easier, but it does nothing for the managed, except lead to frustration and hundreds of emails that have to be waded through for that 5% chance of relevancy.

Their integration seems particularly targeted to JIRA, when they've lapsed on many other useful features and improved UX implementations. It reflects GH's priorities as a company.

It's a sign that github is catering to management over the programmer. Contrast that to gitlab, whose implementations are designed to make the programmer's job easier.

Honest question.

JIRA has a tendency to.... decay. New ticket types are created with custom fields that aren't ever kept up to date. Everyone starts to choose random entries because they have no choice, and no way to add new ones. Once that starts, things fall into chaos because nobody knows the "right" way to file tickets. Tickets soon become immeasurably immeasurable. Projects become categorized incorrectly on a constant basis. The only people who know how to use JIRA effectively are the ones who know how to ignore all the noise. Once those people leave, you're left with pure, unadulterated chaos.

And then you get people who try to fix it by adding a new ticket type or project group, etc. Rinse, repeat.

If you haven't already, then you should check out JIRA's query language and its API. The query language is... special (and doesn't support wildcards, last I checked). Its API, instead of displaying field names as you see it in their interface, shows "fieldname_21234". No joke. You have to run another api request for all of the field names and associate them yourself. It's painful

To your point - sure, JIRA can be used effectively. Though, any bad tool can be used well if enforced. But that's not what most of us have seen in the wild. JIRA eventually just becomes a behemoth of a tool.

It is anyday better than getting tasks over email.

We had very minimal customisations. A simple set of swimlanes that we update throughout the product development process.

From what you are telling it looks like your team had other problems in delivery. You tried to solve it via Jira by adding new custom fields and forcing people to update them. Solving the deeper issue would have helped there.

I have been able to track my deliverables. See how my team is performing. Plan for the next sprint. Perform retrospectives and capture action items. The tool hasn't broken while doing this. UI is decent. I really don't see a problem with the tool, it serves its goal.

Is there any enterprise scale tool that doesn't, when it isn't managed correctly? It needs management just like any other tool that's being used on an enterprise scale. People just want to be able to set and forget, but then it doesn't adapt well to individual departments and teams. Then people either start messing with it, or if they can't, they start hating it.

The benefit of a smaller tool is then, that teams can just get their own instance and mess that up without impacting the organization.

With Jira, one can create project-specific issue types, fields and workflow.

All that is to say, a human problem is fundamentally a tool problem.

1) It's sometimes a tool for managerial micromanagement, such as the extraction of unreasonably certain estimates as "promises", which can then be adjusted further down by your project managers, which can then be used to pressure devs into crunch or worse, instead of as a means of adjusting expectations.

2) It's an extremely complicated piece of software which you can (read: will) overcustomize into oblivion, confusion, and general busywork. Having grown over the years, it's various complications are also not consistent with each other, so some features don't really work well with others. The antithesis of KISS or YAGNI.

3) Project managers will still ask you about stuff instead of referring to JIRA. What's the point of sending time estimates into the void if they're going to swing by and disrupt your flow to hear those same estimates from you in person anyways?!

#1 gives people a (reasonable) emotional reason to hate JIRA, #2 gives people a (reasonable) rational reason to hate JIRA. #3 probably counts for both. I feel like I'm the weird one out not having come to hate JIRA in my social circles.

Project management is important, but JIRA is just a tool, not project management. Ultimately, that's a communication problem with your stakeholders and the people who get to call the shots. Email, slack, trello boards, even water-cooler chit chat can be better than an over-configured JIRA install in the right hands with the right managers. Get everyone on the same page in terms of tasks and priorities, manage expectations, track progress, avoid last minute surprises...

Something like a Trello board is sometimes popular with the "JIRA is overcomplicated" crowd. I use it for personal projects sometimes. It's OK. I'm OK with JIRA in the right hands too though. You don't have to tweak every single knob and settings. You can practice some self restraint and avoid it nerd sniping you, probably.

Our team grew to the point where we needed a bigger license, so we just migrated over to Jira Cloud. And it was even slower than the on-prem install.

No "no project management" isn't a better solution. No, I can't name any alternatives off the top of my head that are better than jira. But holy cow, jira is not a good piece of software. It has a lot of great concepts, but it runs like garbage and really isn't THAT fancy for what most people require. Especially for the cost.

It's not good, but it's not exactly a risky move either. "No one ever got fired for choosing IBM."

Good project management systems are simple and frequently not completely technically automated. Trello, or its older cousin "index cards on a whiteboard" are popular. Regular GitHub issues handle much of what needs to be handled, as long as you impose an organizational policy for how you'll go about triaging and updating status in them. Scrum stand-ups are just... regular meetings. None of this is very fancy; none of it needs to be.

The Jira environment I’m currently working in, takes 2+ seconds for any interaction to update the interface (that’s the sped up version. People tell me it used to take 20...).

Creating a new ticket displays no less than 150 fields (not all of which are required, thank god).

This is excluding Jira's design, which frustratingly makes you click several times to uncover data that should be obvious, and various other minor issues that just create headaches, for example: estimations for individual tasks don't bubble up for stories or epics, so you can have two wildly different sets of data to maintain.

The alternative systems would change depending on what people's issues with Jira are -- i.e are they design-based or ideology-based.

Jira's just a tool, a tool with an API, if it burns you so much then set up an email filter and spend a weekend on some GitHub-workalike wrapper or whatever other tool you believe does a better job. God I hate the damned thing, but placed beside all other similar tools in its class, I'd recommend it any day of the week, including over the joke of a system GitHub supplies - hell the ancient Bugzilla even compares favourably with GitHub.

The sad part is... yeah, you're right. It's the best ticketing tool I've used, too.

I'm not sure what the solution is. My naive thought has always been that good management can mitigate most of the need for JIRA - even at large companies. Management like https://en.wikipedia.org/wiki/Kelly_Johnson_(engineer), perhaps.

The saying is JIRA is yo project management what PowerPoint is to public speaking. For people who are good it can marginally improve the output but for most people it’s an easy way to wank away your time convincing yourself you are working on the right thing as you ignore the real issues.

Replace "yourself" with "others" and you have the answer as to how Jira makes managements life easier ;)

Personally I’m a fan of a physical Kanban board. This definitely scales far worse than JIRA does.

Does it? I think there are compelling arguments against it wrt remote employees. But I've seen no evidence that once you get bigger than a project that requires more than a physical Kanban boards any project synchronization becomes a farcical activity.

That's almost too easy to counter, having worked at a startup with just 3 employees, all devs, and no typical managment whatsoever. Jira was and after like 10 years still is, the go-to tool for bug tracking and it does the job just fine, after a one-time and somewhat lengthy setup phase. Which is obviously nothing compared with the years of use..

Speaking of >making programmer's job easier<, we could say that GitLab Auto DevOps eliminates the complexities of getting going with automated software delivery by automatically setting up the pipeline and necessary integrations, freeing up yourself to focus on the culture part. That means everyone can skip the manual work of configuration, and focus on the creative and human aspects of software creation.

Here's more about it https://docs.gitlab.com/ee/topics/autodevops/

I was afraid the acquisition by Microsoft was going to lead to it becoming more enterprise-oriented and less user-oriented, and it appears like that's exactly what's happening.

I don't mean that to come across snarky at all; I'm honestly curious what people are using and enjoy.

(We are coming from Trello which just doesn't deal well with a large number of tickets as you have only one view on them.)

People don't want to have to update whatever project management team their management uses.

Good News! That's why this integration exists.

1. This integration lets developers work on their code while automatically sending updates Jira so they don't have to.

2. When you create a commit, it can automatically transition a Jira issue so you don't have to go to Jira to do it.

3. Use smart commits to update the status in Jira, leave a comment, or log time without leaving your command line or GitHub.

4. When you create a branch in BB or GH it will automatically transition the issue in Jira so you don't have to.

5. When you merge a pull request in GH and BB it will automatically transition the issue in Jira so you don't have to.

6. Linking Jira Software to GitHub lets you see branches, commits, and pull requests right on the Jira issue.

7. Now everyone, even those pesky managers and program managers can see the status of work without asking you to take your headphones off, “bumping” their email in your inbox of “pinging” you for the 10th time in Slack. They can see your status right from the board without even clicking into the issue. 8. Search for Jira issues based on related GitHub information, such as open pull requests.

https://www.atlassian.com/blog/jira-software/github-for-jira

Since we always care about transparency, everyone can read more about it here https://about.gitlab.com/features/gitlab-ci-cd/. Also to mention the documentation where you can read about the first steps towards your GitLab CI/CD journey https://docs.gitlab.com/ee/ci/

GitHub earned trust from enterprise and open source community alike. Stable, robust, secure and reliable. Competitors try hard but they're not even close. Everyone's happy.

One day, they announce, they are bought up by a rich, notoriously closed source software behemoth that was once sued for its monopolistic tactics. It claims its now a changed company wanting to empower developers to build the future and the only way they can do that is by buying GitHub and promises to do their best work to empower every developer to build, innovate and solve the world’s most pressing challenges.

4 months down, they declare they've built a close integration with a proprietary, overpriced issue tracking tool that is described as slow, terrible, unproductive, confusing and an utter nightmare by its users.

See it now ?

In fact both tools effectively compromise the underlying concepts they encapsulate.

GitHub for example ties you to a very centralised model. The moment there’s a github problem, the whole “post push” workflow falls to its knees. Forget CI, PRs, everything. It’s down or working incorrectly or inconsistently until github find the poo and shovel it. When your old self served SVN server had downtime measured in seconds in a year and your build infrastructure was several orders of magnitude more reliable. Genuinely, it’s worse and needs more humans to keep it ticking on medium sized teams. That’s less humans on adding business value.

JIRA itself is an interesting tool. The tool itself has its own problems (abysmal performance mainly) but the main problem is that it has a propensity to be configured by people who don’t know or understand it. That results in many staff effectively running around in a hamster wheel every time they have to do something trivial.

These two together multiply and you end up with thousands of hours of developer time thrown out of the window. This is seen as the status quo of development but it doesn’t need to be.

We need better more reliable tools, not better integrations between pits of despair. Also we need a firm stick to beat the workflows into shape.

I agree that the negativity doesn't seem warranted, but plenty of people are being forced to use Jira or GitHub in their daily routines.

Sort of like how "my brain" forces spicy food on "my intestines", but when you model the two things together as a single human being, then you can confidently state that nobody is forcing me to eat spicy food.

Really, all the GP is trying to say is that neither Github nor Jira has any external market forces colluding to push those products onto "software-buying entities" (like individual freelancers, or whole corporations) that don't want to use them. They're just products, in the market, with freely-available alternatives, and any entity who would normally have the power to choose which software to buy, isn't having that decision made for them by market-distorting forces. There's no Github or Jira monopoly that has come along and crushed the alternatives out of existence, such that they're the only options even if you, a software-buying entity, wanted to buy an alternative.