Trello, “Jira Sucks”, and Tool Dysfunction

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...

Ya, so it goes I guess. Was actually looking forward to something more organized after having no process to speak of for a year. And it's not even like the estimates get held over my head much or anything, just that putting in sub-tasks for..

1. add input box 2. create functionality to store input box value 3. have next page display value

..and keeping track of the time spent on each step is reeally annoying.

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...

Having used other issue trackers over the years, Jira isn't exactly a shining beacon of excellence. The UI is hard to navigate, the screens are inconsitant, the JS breaks on occasion so buttons stop working, it's slow, has horrible defaults and is far too flexible in some areas but miserably inflexible in others (usually where flexibility would be useful).

All in all, it's not a great product. It can do the job, most of the time, but costs a lot of time (and therefor money) to get it set up even close to adequately.

Jira is indeed a tool, and it can do the job, but in comparison with other tools that also do the job, it costs too much for people to stop saying it sucks.

A siloed mindset doesn't come from that. But it is encouraged by it. Whereas tools that present a unified view of the work (e.g., [1]) encourage a unified view.

I agree a great team can use whatever and have things still work. But most of the people buying tools are hoping they will help solve organizational issues. So it's the non-great teams that concern me most when we're talking about tool selection.

[1] http://williampietri.com/writing/2015/the-big-board/