[gravypod]

The team I'm on currently uses JIRA but I would harshly recommend against using it. It's one of the tools on the belt of the Agile Clergy that is used to beat the peasant into submission.

The tool is expensive, constantly deteriorating in visual appeal, workflow, and support, and over complicates very simple tasks. The Agile Clergymen who work at my office boast it's integration abilities, it's high customization, and 3 charts it produces that inevitably say "You're not Agile enough" as being all one would ever need for a project management system.

In my opinion there are three main options right now.

If you're hosting an internal Software Development-only ticketing system that only the PM and the developers will interact with, and you are using GitLab, and you have the ability to host a robust GitLab server internally, I would recommend GitLab Issues [0]. It's free and open source and very integrated with the entire workflow even including time-tracking, gantt charts, etc. It's all bundled into what they're calling a Portfolio Manager [1] that has a bunch of other features you may want to explore as a PM.

If you want to use JIRA because the Agile mob is present within your organization it is a fine option so long as you either don't mind spending a very long time figuring out how the unnatural interface works and setting up a bunch of essentially needed "customization" then you can look into that. It even produces 3 pretty nice charts!

If you specifically need to take in issues and triage bug reports and feature requests then you may want to look into Redmine [2] or BugZilla [3]. Both are extremely dated but have been tried and successfully used by many large teams.

[0] - https://about.gitlab.com/features/issueboard/

[1] - https://gitlab.com/gitlab-org/gitlab-ee/issues/3254

[2] - https://www.redmine.org/

[3] - https://www.bugzilla.org/

[DanielBMarkham]

I've been an Agile Tech Coach for ten years now and I actively recommend against JIRA -- or any other online tool for that matter.

Whatever you want from your tool, the goal is to keep it as simple as possible so you can actually work. If you've got your head stuck in an online system for any length of time during the day, you're not doing it right.

Tools, whether PM tools or not, are supposed to disappear so you can focus on value. If you're talking about them, spending time in them, going to useless meetings with pointless reports generated from them, etc? They stop being tools. At that point they become obstacles. Carpenters don't go to meetings with graphs of how many hammers they own. Brick masons don't spend half a day comparing the status of all of their trowels. Project Management has jack squat to do with configuring and using PM tools. Unless you're specifically training on skills, tools should disappear. That's the entire point. I wish more people knew that.

ADD: Do you know the people who do focus on tools and talk about them a lot? People who don't know what they're doing. To them, the feature list of any tool is reassurance that they can continue not knowing what they're doing and somehow things will still work out fine. The tool will handle it.

[gravypod]

> Whatever you want from your tool, the goal is to keep it as simple as possible so you can actually work.

> ADD: Do you know the people who do focus on tools and talk about them a lot? People who don't know what they're doing.

This to me proves you're not in the bubble of people who I talk about when I say "Agile Clergy".

[DanielBMarkham]

I find the worst people to deal with are those who have already tried Agile and love it -- without all the experience that a few dozen teams gives you. To them, as you point out, it's much more of a religious thing.

I remember my first coaching gig. I was looking to dive into a team, get into the code, make things happen! Instead, I spent the first day in what could best be called religious discussions. It was quite odd.

But in their defense, they had no context. Agile was an abstract and nebulous thing. Instead they all had heroes/demigods that they looked to for advice from on-high. The focus was on "being correct"; tool features, usage, and adoption; having a good time with the teams. All sorts of crap instead of just making stuff people want.

I see the same thing in management, with or without the Agile part added in. Once you get removed from value delivery, even if it's only just a little bit, you end up adrift at sea. So many of the management schools are just as religious as the Agile folks. They just have different demigods :)