Trello, “Jira Sucks”, and Tool Dysfunction
hackernoon.com
hackernoon.com
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.
how do you balance a very powerful product and simple day to day uses of it?
I imagine it starts with always considering the thing as a product, not as its features, so that you can always make sure all the work being done integrates intuitively and intentionally into the original thesis of the product.
The very fact that one has to hunt through various layers of oddly organized configuration screens (several of which do almost the same thing), and has to often click on more than one "..." menu to poke around looking for assumed-to-exist functionality before actually finding it, is an indicator that JIRA might be developed as an ongoing train of user stories to create features unmoored from a central thesis.
Because if it was developed like a product in total, then its metaphors would be consistent, its language would be consistent, its modes of interaction with those metaphors would be consistent, and intuitive organization would largely fall out of that.
Used JIRA for 7 months now. Can't understand how people get anything done and tracked with it (trying to forcefully carve teams into a per-the-book SCRUM methodology with 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.
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.
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...
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.
> almost every complaint I've ever heard about JIRA could be remedied by a better implementation.
Huh? You're replying to a complaint about the UX.
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.
Is this really how most 'agile' shops work in this industry?
Either management understands software development or they don't, and it's not something you can really teach them either. I don't need my managers to know our stack or even be capable of developing working software themselves, but it's hard for someone who's never spent 6 months working in the coding trenches to understand the amount of uncertainty inherent in software development.
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.
Was looking for something more along the lines of "PM at [cool unicorn] says none of the cool kids do X anymore" but maybe that could work.
Just clicking on create issue takes 4 seconds. Switching between issue types takes about 1.5 seconds.
This should all be just simple javascript change and layout calculation but there seem to be network requests for every single click.
To me, that sucks a little.
I just don't see how it is acceptable in 2017, with added insult that the amount of data displayed is tiny.
Not sure why manager types like JIRA though..
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 :)
I think the tool itself isn't that great. When you try to be all things to all people, it's easy to be tolerable for most and great for nobody. But the real problem is what it represents: a straitjacket for teams, used to force them to work in ways that people with political power deem appropriate.
The Lean Manufacturing folks put bureaucracy into two different categories, supportive and controlling.
Supportive bureaucracy is bottom up. E.g., by my door I have checklists for what I need when I'm going out running or swimming. Nobody makes me do it; I just was tired of forgetting something. Good teams do similar things, like an estimation checklist or a written-up release process.
Controlling bureaucracy is top down. It's where other people use systems to force you to work like they think you should. They're used as a poor substitute for trust. People experience Jira as sucking because it's a instrument of control, and controlling bureaucracy sucks.
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.
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.
Was lightning fast, not crumbling under the amount of issues and projects we had, and interface much cleaner. I understand there's a ton of complexity in JIRA that we didn't use and they didn't have to implement, but anyway there's no excuse how unwieldy JIRA core functonality is.
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 <Add>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.
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.
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.
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?"
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.
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.
Our team works as a very unified team despite having the ability to pull up specialized views of their own work. Tools that prevent people from focusing in on their own work are no substitute for good communication.
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.
(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)
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!
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 :)
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...
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.
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.
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.
Not from the moment we make the first ticket, though.
> 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.
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
Similar to MS Office popular comment, by Joel Spolski I think, everybody uses 20% of the features but everyone uses a different 20%.