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.
I've both loved and hated JIRA. For me, it all comes down to how well set up it is. Its configuration over convention approach leads to many installations being poorly configured and often hacked together.
Other than finding out about that practice in the interview stage and using it as a yellow flag suggesting that it might not be the job you want? Not really.
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.
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.
I would approach this differently. The question to ask is, "How can I convince the manager who has authority to make change X, that switching to Y will benefit him/her personally? How can I show them that the change will decrease the hassles in their life and/or lead to higher compensation for them?"
In my case, opening a Dashboard takes 2 seconds and searching the full DB for text takes also 2 seconds. However, we only have about 2000-3000 issues in various projects in our DB.
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" .
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 :)
The times I've see it used, Jira is purchased and configured by centralized people with institutional authority, and then given to teams to use, like it or not.
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.
Among similar tools(HP Quality Center/VersionOne/Redmine/ServiceNow/Bugzilla/Trac) I have been using at work for the last few years, Jira has always been the most intuitive and user-friendly, at least from the developer perspective.
The others might have caught up with it by now, maybe there are new better alternatives(please let me know about them) but I agree with the author that the most of the criticism comes from the people who tend to associate the bad processes they are forced to follow at work with the tool itself. Of course the downsides of Jira mentioned in this thread are all valid, but I don't think they outweigh its benefits.
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.
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.
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
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.
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.
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!
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.
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.
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)
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.
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.
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?"
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.
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.
A siloed mindset doesn't come from giving people personalized views of their actionable work. And making those views available doesn't prevent people from opening the other views or seeing the big picture.
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.
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.
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?
I remember how at one of my previous employers tools team got frustrated with JIRA and created their own knockoff in something like a half year.
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.
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.
JIRA has some specific UX problems in some of the oldest parts of their product which they've been consistently ignoring in favor of multiple menu redesigns.
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.
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.
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.
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.
That's the thing -- it's (no longer) easy at all. When accessing every other function requires guessing which hamburger menu it's hidden behind, it looks clean and easy to use, but it's not.
It's still overwhelming and complex, so that part has stayed consistent.
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.
You don't. You don't use "very powerful products" for "simple day to day uses".
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).
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.
> 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.
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...
> 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.
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.
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 :)
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).
70 comments
[ 5.8 ms ] story [ 145 ms ] threadI 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.
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.
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
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.
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!
Not from the moment we make the first ticket, though.
(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)
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.
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.
[1] http://williampietri.com/writing/2015/the-big-board/
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.
> 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.
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.
Similar to MS Office popular comment, by Joel Spolski I think, everybody uses 20% of the features but everyone uses a different 20%.
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 :)