Trello, “Jira Sucks”, and Tool Dysfunction

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.

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.

One example off the top of my head... creating filters (custom lists of issues - stored JQL in fact)

- why do filters have permissions at all?

- why do they always default to private so that I forget every time and share a link which no one can read?

- that UI around ing groups to a filter for permission is a disaster

...that's one example but to me it's symptomatic; PMs at Atlassian jumping on shiny-but-safe things while shying away from the stuff that matters on older features, which may carry legacy.

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.

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 :)