[madeofpalk]

Sliding in here with the hot take, but Jira can actually be pretty good! Github is terrible at project management.

The problem with Jira (or at least used to) is that it has so much complexities that let people make it overly complicated.

[eyelidlessness]

I hate that I agree with this but...

I soured on Jira because my first experience with it was a horrible Rube Goldberg configuration on a self hosted instance.

Years passed, I tried a bunch of different ways to use GH Issues as a primary tracking tool. It works but it’s... blah. It’s a good outward facing tool, it’s not good for tracking internal work. Because there’s no organizing principle.

My last job forced me to use Jira again and, don’t get me wrong! It’s still bad. But given the nature of my role in that job I ended up setting up a new board and I was pretty amazed to discover that you could set up a new project with relatively sane defaults. And you can turn most of the complexity off and get almost bare bones Trello.

The only thing I couldn’t sort out to make it habitable: I really wanted to disable the “sprint” concept and have a single board without gymnastics. I don’t know if that’s just baked in or something the company configured.

In any case, that bare bones Jira setup was basically functionally equivalent to GitHub Projects, and surprisingly a better UX. Neither are great, this isn’t praise for either. But I’m just owning my bullshit and admitting I was surprised that the (now year old) modern Jira UX surprisingly didn’t torture me as much as I expected.

[CRConrad]

> The only thing I couldn’t sort out to make it habitable: I really wanted to disable the “sprint” concept and have a single board without gymnastics. I don’t know if that’s just baked in or something the company configured.

FWIW: We have sprints in JIRA at work -- but at my previous job we didn't. I doubt they've been added to the product in the couple of years since I left my previous employment, so I'll guess it was configured not to use sprints there, and still could be now.

[eyelidlessness]

We must have missed each other on passing trains. My experience was that sprints are not just built in but required. I set up my last project with a catch all “active” sprint that never ends, and a catch-all “later” sprint that also doesn’t end for stuff that’s not being actively worked on or considered.

[CRConrad]

Hm... Maybe that's what we had at my old job too, then. Perhaps someone had set all that up before the rest of us in the team ever got to see it, so we never noticed.

Has the "Sprint" link always been on the bottom of the rightmost column?

[typeofnandev]

>The problem with Jira (or at least used to) is that it has so much complexities that let people make it overly complicated.

I actually really like this take, because a lot of the times it feels like a tool's complexity is from what it lets you do. I feel like if Jira was "dumber" (i.e., less feature "rich") it'd be so much better.

[gregmac]

I was previously a JIRA admin, and what I very quickly found was making the workflows the least restrictive possible was the most effective. JIRA itself is quite feature rich and that can be abused, but using it to make your configuration relatively "dumb" makes the actual user experience a lot better.

I very actively pushed back on any requests to add additional states, but nonetheless there were several of them though mainly to facilitate kanban columns and way our dev and QA people worked together.

I think the biggest thing is I ended up adding a ton of transitions between workflow states. Eg: "QA in progress" straight to "Dev in progress" was allowed, as was pretty much any state to "Closed" (so long as resolution was wontfix/invalid/etc). It took lots of time to get that setup properly and ensure transition states had the right name (so the button in the UI had a logical label), but it was well worth it.

The only real workflow restriction we had was that to set an item to "closed" with status="resolved" it had to have a fixVersion assigned. This was a trivial thing to deal with day-to-day but made the list of closed tickets immeasurably better (eg, building release notes, or tracking down what versions a bug affects based on when the feature causing it was originally introduced).

Comparatively, I've used JIRA in a massively locked-down state -- where there are tons of required fields, very prescriptive workflow that often requires 3-6 transitions to get from one state to another, specific roles required to do transitions -- and it sucks. It makes the ticket content and statuses worse (not better) simply because everyone hates using it.

If people aren't following the team's process (such as devs clicking "QA passed" without doing QA), that's a people problem, and it isn't going to be solved in the JIRA workflow editor.

[madeofpalk]

To be clear - you have to go in and actively make Jira worse to make it bad. If you stick to the modern defaults and don't add in additional workflows you'll be fine.

It's certainly an indictment of Jira and it's technical legacy that it lets to make it bad.

[aunty_helen]

I worked at a company that created a team of people to go in and actively make jira worse. Of course that's not what it was envisioned as, their actual job was to make jira fit the stakeholders requirements and buiness processes we had.

However, sometimes your crappy 60 person company doesn't know what's best. If jira didn't have the ability to make it crap it would be a better product and people would update their processes or maybe just try not to smush existing ms CRM workflows into a tool for devs.

[dragonwriter]

> If jira didn't have the ability to make it crap

Then your managers would buy a tool that did instead.

> maybe just try not to smush existing ms CRM workflows into a tool for devs.

If your employer wants a tool into which those workflows can be smushed and wants devs integrated into those flows, that’s what they’ll get.

Blaming a tool for supporting your management’s desires is...missing the people obviously responsible for the working conditions that are frustrating you.

[aunty_helen]

Jira existed as a better product before this and gained popularity without this functionality. I used and championed old jira in this business but hadn't used it for some time.

A better realisation would have been that one tool isn't going to integrate everything in your business from developing software to dealing with customers billing.

[dragonwriter]

> A better realisation would have been that one tool isn't going to integrate everything in your business from developing software to dealing with customers billing.

The trend (e.g., ERP and BMS) is definitely toward that in a much deeper way than broad use of JIRA alone represents. The “better realization” is probably more subtle, and involves more respect for the line workers in defining how their work is done and what the requirements are for the components of a broad enterprise-wide automation system that they interact with are, and balancing that with the information preferences at higher levels so that the latter are satisfied (and maybe compromised in some ways) in a way which preserves the ability of the line workers to deliver business value.

But, in either case, not having that realization is management issue, not a tool vendor issue.

[CRConrad]

Sure, but that still sounds like it was your management that should have had this realisation -- but didn't. That's a fault with your management, not the tool.

[steveklabnik]

This is why I prefer Issues. The lack of features is a feature.

[dleslie]

I happen to agree.

I miss the data analysis tools Jira had at its disposal, and the ability to create home pages with all sorts of graphs, todo lists, and so forth.

Since last using Jira I've never felt nearly as aware of the state of a project as when I did.

[porker]

Yes, dashboards are underrated by those who haven't used them.

The data analysis tools did cause problems at one company I worked at. They had a very locked down JIRA install and management were in thrall to the burn-down chart. If you got behind you were hauled over the coals.

The burndown chart only considered the rate tickets were closed. So developers started creating extra tickets at the start of a project, so that when they got behind on a larger issue they could closed off some of the small tickets and the chart would stay on track.

Management never spotted.

[dleslie]

Ha! I was a team lead at a company where something similar happened. Management was obsessed with the burn down chart and equated total completed with productivity.

So I told my team to make tasks as atomic as possible. If it can describe two meaningful changes then it should be two tasks.

I actually preferred this outcome. Instead of a large task for a feature, we had hundreds of tiny tasks that culminated in a feature. It was far easier to get a handle on what was getting done and what was the impediments.

[Talanes]

For some reason, plenty of people in management don't seem to realize that raking people over the coals over individual data-points just incentives your workers to avoid giving up data.