
Trello, “Jira Sucks”, and Tool Dysfunction - tablet
https://hackernoon.com/trello-jira-sucks-and-tool-dysfunction-e80c8000a431
======
im_down_w_otp
The biggest issues I have with JIRA have to do with it being one of the
world's most inconsistent, unintuitive, and undiscoverable UX's possibly ever
made. All manner of things are hidden in "..." menus, and any screen will have
several such menus visible at once, but they're all different. It feels very
much disjointed and like the UX is done in a deeply siloed process that
considers only the most local region of the screen the user could be working
in (or where a feature lives), and like no attempt is made to consider the UX
as a whole.

It feels like using 15 different independent apps at once that just happen to
be crammed into adjacent or overlapping screen real estate, and each one is a
different lens with its own side effects that come from interacting with it.
Some things are randomly modal and others aren't and require you to actually
load an independent details screen. The only significant consistency to any of
it is the fact that it all shares a somewhat common graphical style.

Despite having used JIRA for a decade or more, at no point do I ever feel like
I know where I'll find something on the first try or know what's going to
actually happen when I deviate even the slightest from the very, very narrow
repeatable process groove I get into after much trial and error.

~~~
manyxcxi
The thing about JIRA hate (or love), is that it only has a little to do with
the actual product. As the article says, crappy process will give you a crappy
experience. But a crappy configuration will do just the same. If you're
constantly hunting behind menus to get to stuff it's likely that they've
enforced some process on to you but not properly reconfigured the screens or
transitions so that you get what you need when you need it.

It took a bit of trial and error but on my team we can work almost exclusively
from our agile board and have transition screens configured that will collect
the info we need when someone is moving things around on the board.

Now, don't get me wrong- the UX needs a lot of work because it is so
inconsistent, but I feel like almost every complaint I've ever heard about
JIRA could be remedied by a better implementation. Maybe not solved
completely, but remedied to a degree that it's not too bad.

~~~
Domenic_S
> _every complaint I 've ever heard about JIRA could be remedied by a better
> implementation_

Erm... what _can 't_ be fixed with better implementation?

My big point of hate on JIRA is how it uses some mutant hybrid of markdown and
wiki text, so going between JIRA and Github is a nightmare of context
switching. Can that be fixed with a better implementation, of course it could,
but the point is Atlassian doesn't seem to think about UX.

~~~
manyxcxi
What I meant by implementation is that you can implement your company's
processes via JIRA configurations, workflows, and occasionally plugins in such
a way that the way your instance operates is almost unrecognizable from the
way someone else's might.

You can configure a nearly infinite number of input screens with all manner of
standard and custom fields to be presented to users at any given point. The
rules can be quite complex and handle forward and backward transitions. As a
system administrator it can totally be overwhelming, but you are quite free to
do most things.

If you have a process that default JIRA configurations doesn't serve well and
drives users into deep menus and weird contexts, you can very likely fix it,
or at the very least make it more palatable with those customizations.

For example, for a given project type, we don't just have To Do, In Progress,
and Done. We have To Do, In Progress, In Review, and Done. When a dev moves
from In Progress to In Review they are prompted to input a number of required
fields so that QA can know how to test it, where to look for it, etc. If QA
fails the review, they're prompted with a specific screen that brings forward
the inputs they'd need to document why it failed. When they fail it, it
automatically goes back to the dev that kicked it to review. When that dev
kicks it back in to QA it's going to go back to the person that reviewed it
the first time. This process, if done with no extra JIRA configuration would
be a damn nightmare and it would break down fast. We spent the time to make it
fast for everybody using it, and to make sure that they are presented with the
things they'll need when they need them.

If JIRA is new to a team I recommend they run it completely vanilla for a
while and then come up with a list of things they'd need it to do or do
differently to fit their meatspace processes and interactions. I'd also look
at what you could do to make your existing processes more streamlined that
might cut some of the complexity in the first place. Vanilla JIRA Agile is
actually fairly simple and only more complicated than Trello because of the UI
and various issue types. You'd be surprised how far it can take a team if you
don't have some arcane internal requirements or unrealistic expectations of
the software revolutionizing your team's performance. At my last company we
quelled a near JIRA revolt (it was there before me) by literally just going to
default JIRA Agile workflows.

I do agree about the 'markdown' support in JIRA/Confluence. It would almost be
better if they just didn't support anything than the way they support it. I've
got a lot of gripes with JIRA around UI/UX issues, but the vast majority of
hate I hear spewed at JIRA is usually because they had really crappy (or just
complex) team processes implemented with crappy JIRA configurations and it
made everyone's life hell.

I'm not a JIRA apologist or anything, if there was something else out there
that was better and had the same level of available integrations (Jenkins,
Slack, support desks) I would cut over in a heartbeat. I just think it gets a
worse rap than it deserves (not that it doesn't deserve some mind you).
Confluence on the other hand, that deserves every complaint I've ever heard
about it...

~~~
im_down_w_otp
I'm talking about both default JIRA workflows and customized ones.

I've had to be both a consumer and a creator of processes managed with JIRA.
It has no bearing on how objectively confusing and inefficient the UX is.

------
znpy
I have been using Jira at work for the last 10 months or so, and have been
using trello for personal stuff for more than a year and a half.

I dunno, but Jira doesn't looks so bad to me.

To be quite honest, "Jira sucks" really looks like a meme to me, that people
carry around for some reaons.

I am not a jira enthusiast, nor i am endorsed/funded by atlassian in any way.
Jira is a tool to me, and it does it job.

~~~
dominotw
I think people associate JIRA with middle managers who "work" all day in JIRA
and foist draconian JIRA "processes" on everyone. eg: My current manager wants
us update all open JIRA tickets every morning with "current status" .

Not sure why manager types like JIRA though..

~~~
base698
I hate JIRA, but I noticed something. If I tell people to do something, they
won't do it. If I create a ticket in JIRA it has a much higher probability of
getting done. It's not been too bad, after I got over the hate of not having
real markdown and the 100 fields when a ticket is created that are mostly
unused.

I prefer little to no process, but the work has to be organized some how, and
using git with emacs and org mode wouldn't be nice to most :)

~~~
_asummers
Not sure if you've seen the org JIRA integrations, but you can effectively do
ticket management in org-mode.

------
alkonaut
> When I ask this, I’ll often hear about benefits like tracking,
> accountability, visibility, estimation, managing dependencies, status
> checks, notifications, executive roll-ups, and reporting. I hear very little
> about improved collaboration, better insights, improved quality, more
> effective retrospectives, and increased team motivation / sense of ownership
> / clarity of mission. I almost never hear about improved end-customer
> outcomes.

I agree with the author. Enterprisey tools for enterprisey use cases are
probably detrimental to developer efficency, motivation, and probably also in
some respect to end-user outcome.

But what the author doesn't address is that those enterprisey behaviors aren't
there for fun. There are tons of levels of management that need to see those
charts. You could argue "then fix that!" but then please tell me how to do
_that_ instead of telling me what tools I could use _once that is done_. I'm
going to argue that for a lot of enterprise development this isn't possible.

I don't hear a lot about huge teams of mediocre developers developing large
scale software with managers on all levels having the level of insight
necessary to keep stakeholders happy - while doing all tracking in a simple
trello board.

Now I'm not going to argue that TFS and Jira are nice and nimble. But the
alternative to these aren't Trello, they are Trello + fifteen different secret
steps you need to take to complete the now ad-hoc process.

"When you finish an issue you need to email the QA lead with the build number
to test in, then email the required translators to fill in the necessary
translations, then move a thing on a board somewhere, ...." Unless all these
things are magically not required, then I very much prefer digging a deeper
Jira pit where all of this is at least encoded and enforced in the system
rather than in a wiki or email somewhere.

It's not management that pushes these systems on developers. Management push
the _process_ (because you lose track of e.g. which translations were missing
and you had an embarassing release somewhere). Developers then use the tool in
response, because to developers, software is the answer.

------
bshimmin
There are definitely ways in which JIRA sucks: it's hard to configure and
requires someone with special skills, knowledge, and enthusiasm (!) in order
to get it right; it definitely could and should be a lot faster; navigating
around it is fairly bamboozling for the inexperienced; and certainly other
things besides. But, with all those caveats noted, is there actually another
product on the market that does as much and is any better to use?

~~~
everythingswan
This is essentially my opinion of it. I look at both Trello and JIRA as
useful, depending on my use case. With a cross-discipline team focused on
delivering a few things (basically epics/features/whatever) at once, I love
JIRA. Working on my own, I'd use Trello.

It has a similar feeling to the hatred for Excel we all have as we start to
use it. So. Many. Features. When you have a team member who is a power user,
it can be frustrating since they will want to lead the implementation. Then
you run into a bottleneck when they are the only ones that can run/fix that
report. Maybe not a great comparison beyond that.

I like John's take on it that you should start with a simple, physical board.
If I start with a new team that will be my preferred path.

I joined a team on Asana and we simply used the list type for a project with
acceptance criteria. Not a physical board but it was super basic. Over the
next 3 months we started to add colored tags for epics, important links to the
description during the sprint, & links in the description to related stories.
When it became JIRA 6 months in, we moved to JIRA.

If we would have started with JIRA there would have been a riot. But now that
we know the features we need, we don't find it bamboozling. It still can be
for features we're figuring out we need (I spent 3-4 hours on a simple plugin
last month), but the attitude is definitely not the "JIRA sucks" mentality
that I hear a lot about.

~~~
tablet
I think it is possible to create a tool that will grow with the company from
simplest setup to full blown PM tool with time.

------
falcolas
My problems with Jira:

Permissions around issues and their state are so granular they beg to be
abused.

Permissions aren't granular enough to allow teams to individualize their
project's workflow as their needs evolve.

Jira constructs like states are reused in weird ways for other functionality.
My favorite is the abuse of states to try and implement kanbahn style
swimlanes; states which are global to an org and can thus get odd workflows
attached to them by someone else.

Administered with a light touch, Jira can be fine. But it's never administered
in such a fashion. NEVER.

------
twobyfour
"Jira sucks" is not a useful thing to say.

Yeah, Jira's default workflow isn't awesome. Yeah, it's a giant pain to
configure an alternative workflow; and the learning curve to do so is
ridiculously steep. Yeah, some BigCorps have configured painfully bureaucratic
workflows in it.

But you can also configure it with a very Trello-like workflow.

Why would you use Jira with a Trello-like workflow instead of just using
Trello?

Well, for one thing, you get additional features even just on the Kanban board
- such as swimlanes.

But the most important reason is that with Jira you get a true database of
your issues. One that you can query with a SQL-like language. And one that
allows you to present multiple different views of the same data.

For instance, we have a main kanban board for one project. We have a main
board for another. We have a kanban board that contains some issues from each
specifically for our DevOps person; and another specifically for our QA
person. The QA person's board contains three columns that correspond to a
single column in the developer's board.

I can create an "epic" that contains multiple tickets (not subtasks or
checklist items) that can each progress through the workflow and be deployed
independently but still be grouped together under a single parent epic.

And if I want to pull up a list of all Foo component tickets that were filed
by Bob before June, implemented by Alice, QAed by Carol, and were released in
July - and then open each one in a tab - that's incredibly easy.

~~~
wpietri
I get why you're excited about this, but I think it's a mistake.

One thing I've seen over and over is projects where everybody did their job
and the project still failed. Why? Because everybody was put into silos. Each
person could define success as doing what they were assigned. The developer
built to the spec. The database person made the database work. The QA person
verified that the system met the spec, and the ops person made sure the
servers stayed up. No actual value was delivered, but everybody can say, "Well
I did my job!"

Elaborate systems like this encourage people to focus on output, not outcome.
You don't have a team so much as a umber of individuals who happen to be
working on the same thing. Teams are groups of people who win and lose
_together_. They have a common goal and focus on achieving the goal.

One of the reasons startups are so powerful is that early on you have a cross-
functional team that is intensely focused on outcome. Everybody knows that
"did my job" doesn't matter if the company's going to run out of money in a
year. The incentive is toward a much deeper intellectual engagement. It's not
just, "Did I do what I was told?" but "Am I doing the right thing for the user
and the company?"

~~~
dangoor
I agree about the need for successful cross-functional teams.

But what happens when you have multiple cross-functional teams? Sometimes they
have interactions. Sometimes you have management that needs some visibility
into how things are going.

~~~
wpietri
I agree those are issues, but I've not actually seen Jira solve them.

With or without Jira, cross-team coordination issues mainly get solved by
teams talking.

I've definitely never seen Jira solve a management visibility problem. Even if
a team uses Jira fully, and even if the work is properly represented in Jira,
and even if it's represented in a way that's more about the business need than
the technological process, Jira is still a system for reporting on output, not
outcome.

Just last week I was talking with an executive whose teams use Jira, but he
still has little idea how things are going. He really wants it, but Jira's not
satisfying that need. I doubt it can.

------
lmm
Tools drive the way we use them. If most people using Jira ends up with a
process that sucks and most people using Trello don't, maybe it really is the
tool that's making the difference.

(Jira sucks because it's anti-employee-empowerment by design; everything is
oriented around mandatory fields, mandatory workflows, and requiring
approvals. In theory a good manager should work around this, but defaults are
important. I fear the same thing happening to Trello)

------
OneFishTaco
Been using both for years, at multiple orgs, and can say with confidence JIRA
does suck. Everyone in my org had given up trying to use it, I went through
the pain and don't wish it on anyone... then there's Trello, it just works
expected.

With JIRA, prepare to invest significant pulling your hair out if you want to
use any features. It's amazingly difficult to enable the use of the Trello-
like board feature.

Go ahead, try enabling the "Agile" feature and see, it doesn't work out of the
box!!! Have fun digging through Google to figure out why you're getting
cryptic errors, only to finally figure it's because....

Oh, you have to set up additional permissions to enable it.

Oh, and also enable a certain field (epics) but this needs to happen in the
back-end, as it's some SQL query to enable it.

Oh, but you want to sort issues by drag-drop like a real board? Nope. First go
find the right permission to actually enable sorting!

Oh, but it still wont let you sort! Did you forget to 'sort by ASC' in your
filter query? Otherwise, no drag-drop sorting for you!

Why those things aren't just enabled when you created the board in the first
place, boggles my mind!

~~~
joncrocks
I think the 'Agile' features were actually originally an external plugin
(GreenHopper), so I imagine it's integration ended up making it a bit fragile.

------
emperorcezar
I'm sorry. You're quite wrong. Jira does suck, not because people change their
work flow, but because there are many parts that fail integrating with each
other as soon as you make any settings changes.

------
xaldir
As a Jira administrator, I both love and hate Jira. It's versatile and quite a
good set of tools when configured properly. On the other hand looking under
the hood is quite frightening.

------
tablet
I develop Targetprocess (JIRA competitor in general) during 13 years.

And I completely agree with the article. It is EXTREMELY difficult to balance
product development to have a good enough feature set and bearable complexity.

Here are two very typical feedback we receive from end users:

NEGATIVE. Compare to Jira Target process is way behind. No ticket has the
testing phase. This is very poor by design and it is very difficult to learn,
because so many things on the ticket at a time and cant locate important
things like Sprint or who is assigned and in which state it is? Very badly
designed system.

POSITIVE. It was easy to use, and since I've been forced to use Jira instead
now, I miss so many of the features Target Process had... Sigh. Perhaps some
day we can convince the company go to back to TP.

To be honest, there are more critical references than positive.

I have concluded several rules to myself from my experience:

1\. Developers hate project management tools (rightfully so, in general).
Anything more complex than Trello will be ridiculed and hated.

2\. Teams should be allowed to choose own tools, but then we have a lack of
high-level management overview. In this situation management almost always win
(sadly).

3\. Any serious PM tool should be a Platform with Apps in fact. JIRA is
closest to this, but it is old and legacy have its price, so it is more
complex then required. I expect to see completely new tools that will beat
JIRA in a couple of years (Slack of PM tools :)

~~~
nthcolumn
If I had a choice it would be tp2 - that's a beaut piece of software you got
there... definitely does not suck.

------
coldcode
Jira makes it easy to create a sucky tool, but the real reason is always that
your organization has created a sucky process. I should know, I work for a
large and instantly recognizable company and our process is waterfall in
agile's clothing. Sadly we have to work in a world where we have two internal
organizations, and one uses Jira and the other VersionOne and both are
configured to enforce this watery scrum process.

------
vaceletm
It doesn't have to be this way.

Most PM tools are designed to have a somehow central enforcement of the
process and workflow with some central admins that have ways to change that
(permissions, fields, workflows & all). This cannot be anything but a failure
if the central admin doesn't say NO to 99% of modification requests because
there will always be this influential project manager that will come to "add
this little field I need to track this stuff for $IMPORTANT_CUSTOMER". So, by
design, it will either be bloated (everyone get it's change so bug template is
fat) or useless because the form will be so simple that everything will need
to be managed with text content in comments.

That's why we (Tuleap team) propose an alternative: \- You want a simple
-github like- issue tracker because you are 3 in your team and just a title
and a description, please go ahead. \- You want a full blown, CMMI Level 5,
Spice 3, what not issue, requirement, risk tracker, please let the craziest
process guy do.

What's the difference with Jira (and others) ?

Each "tracker" (issue definition) is local to one project (of course you can
template for re-use) and 100% owned by the project. You are not limited to 3
or 4 central templates that nobody can modify, you own them.

Let say the "simple" team is mad of tracking which component of the
application an issue is raised on or how much effort was need to complete the
issue, in 30 seconds the template is modified and usable without impacting
anyone else.

See [https://www.tuleap.org/how-easy-it-customize-my-project-
trac...](https://www.tuleap.org/how-easy-it-customize-my-project-trackers)

------
hdi
I've used Jira for about two and a half years and although it wasn't that bad
for us, I can see how it might not be a good fit for every team.

Anyway, we ended up using a physical board, which was reflected in Jira for
remote teams. I'd take a physical board over Jira and Trello any day, but
maybe that's just me.

------
maliker
Github issues hit the sweet spot for us between trello and Jira.

Although then we got 6 projects all related to one code base and switched to a
homegrown system.

Our main win was making sure each engineer worked on the fewest number of
projects. Letting people focus improved development speed and reduced
confusion.

------
nthcolumn
I checked search preview and got 'Jira sucks' ahead of 'Jira success stories'.
So yeah I'd say it is a meme now. I don't know if it really sucks that much. I
do think it suffers from that crm configurables disease. I can't believe how
much time people/companies invest in this stuff, almost certainly people-lint.
Often the case is where it is adopted along with Agile as a new shiny
methodology with no in-house understanding of either. In one case I've seen is
my team had created a shed load of data migration issues as tasks and the
business were only communicating issues to the vendor. It was a mess but it
wasn't Jira's fault.

------
JimmyL
I feel like a big part of people hating on JIRA is that it creates a formal
process you have to follow - something enforced by code, and not just "always
move your card to this Trello column first". It’s also so tempting for middle-
managers to generate bogus reports, based on metrics that the people doing the
work know don’t matter.

Even with that, though, I haven’t found anything else as good for linking and
organizing bugs and tasks, encouraging collaboration between departments and
roles, recording discussions and decisions in the place they’re made,
interfacing with the other tools we use to run development, and providing a
rich SQL-like way to query tickets.

When setting up our JIRA, we made a few decisions to try and make life easier
on ICs and hide the bad parts of JIRA:

* Ignore the permissions system. By the end, all we had were site-admins (who can control billing and add-ins), regular admins (who can edit workflows) and “everyone else”. Setting permissions up properly is tricky, impacts a lot of things, and didn’t add any value to our workflows. We preferred to make use of the audit log when weird things happened, and for the most part, tell people to do the right thing.

* Insist that workflows come from the teams. Individual teams were given a standard workflow when they started, but were encouraged to make it their own. Central management had to cope with what the individual teams wanted their workflows to be, and weren’t permitted to make them add statuses or transitions to make reporting easier. The only exception to this was around having to use a common set of resolution options.

* Open up the admin role to anyone who wanted it. If an IC or Team Lead wanted to make small changes to their team’s JIRA, they could just come sit with someone who knew how and work it out. If they wanted to make more significant ones, they received the 10-minute lecture covering the top five things that seem safe but will in reality break everyone’s JIRA setup, and then were given admin access to go do what they wanted.

In the end, some teams used a sophisticated ten-step workflow with granular
transitions, and some used it as Trello – but they were all unified in one
place, linkable and searchable, and had common support for discussion,
auditing, and file management.

~~~
_asummers
I'll add also to periodically figure out what works and doesn't work and why
across the company and expand that institutional knowledge to the relevant
stakeholders / documentation. Your JIRA flow should provide just a little bit
of structure around your existing communication structure.

------
yoz-y
I quite like Jira. Speed definitely needs improvement. But one thing that
would really make my life easier would be a unified syntax between Jira
issues, bitbucket comments and confluence pages.

------
overgard
Sometimes I think the problem is really that two things are being tied
together: metrics and a todo list. Almost every sprint planning it ends up
feeling like tasks are subdivided in ways that make burn down charts look
better. I don't want to say developers are all special snowflakes, but the
problems with time estimates on creative work is well known, and I tend to
wonder if trying to track metrics on these things is fundamentally misguided.

------
kazinator
> _The problem is that we inevitably come to hate every issue tracking product
> we use._

Not from the moment we make the first ticket, though.

------
tibu
JIRA is really good and useful if you know how to use it. We're using it for
several purposes and I love it. Administration side of it is crazy
complicated, for the best things you have to be global admin - this is
something they should fix (but they won't I think because it would make things
backwards incompatible).

------
m0nty
ITT: people saying Jira doesn't suck when the article already acknowledged
that (because the headline is not the article):

> I think that [Jira sucks] is a vast oversimplification, and shows very
> little sympathy to the challenges faced by Atlassian (and the advantages the
> Trello team enjoyed). The problem isn’t Jira.

------
kennydude
I miss using JIRA.

We used Trello, but boards were changed monthly. It was a nightmare. Then
Asana which emails me endlessly and it takes so long to open. And now Zube
which feels weird to put things in which aren't suited to dev tickets and
getting anything right in the balance

------
ausjke
Just use Redmine, it worked well for me and fully open source, though I wish
it is not on Ruby, not thing really against Ruby, but this is the only Ruby
software I had to run/maintain on the server.

------
didip
I think this is the curse of building a popular productivity suite.

Similar to MS Office popular comment, by Joel Spolski I think, everybody uses
20% of the features but everyone uses a different 20%.

------
dep_b
There's just too much in JIRA to make it easy to use. If I need to ignore 80%
of the fields and buttons to work with an application it's overengineered.

------
kelvin0
Jira: The tool that programmers love to hate. Anyways that's how most the
programmers I know and worked with tell me (myself included...).

------
_pmf_
Managers should stick to the rule "if you complain about Jira, you'll get
Bugzilla."

~~~
gozur88
That would be fine with me. I thought Bugzilla was better.

------
jlebrech
JIRA sucks, but it has enough bells and whistles for control freaks to play
with while you just click "done" or comment.

