Funny how much opinions can differ. I've used them both professionally and I think Trello scales poorly above 5-10 people while Jira is the least-worst option for running a project at any team size.
My experience with Jira is that it depends very much on the managers and executive team who set it up and create the precedents on how to use it.
Jira is so customizable and has so many features that it can be made into a sort of bureaucratic prison that's actively counter-productive for everyone except higher-level managers who just use it to generate countless reports. In the worst case, Jira can be used to institutionalize mistrust in employees/developers.
On the other hand, a minimal setup with kanban boards can feel a lot like Trello integrated into a bug database, which can work and scale quite well.
I will say that even a minimal installation of Jira can be overly complex for small teams of 2-5. This is where Trello can really shine.
True. I had to setup Jira for our team and must say it was an awful experience. Too many options, hidden in unintuitive places, awful (too verbose) documentation... Everything is just so difficult. Horrible UX. But it was still the best on-premise solution I could find. Trello on the other side is a delight to both setup and use.
I think buying Trello was great move for Atlassian. No way could Jira compete with them in the long run. And now they are even safe(r) from new Trello-like competitors. Brilliant move for Atlassian. Too bad for us users... :(
Had to do the same thing but had a different experience. It was hard to dive in and took some time but now I understand and appreciate the core concepts. There are many abstraction layers ("[...] schemes") and IMO that is a good thing. When you customize workflows etc. you can do that without leaving supported areas. Creating and changing a workflow is very easy. Plus, JIRA has a good pricing.
With ~350 employees and many mixed teams using only Trello would be chaos. In key areas we need fixed workflows (-> JIRA).
Right now we are planning to add Wekan (FOSS trello clone) to our toolchain for workflows which are more dynamic (less "C follows B follow A" + smaller teams - e.g. innovation and some planning).
JIRA is so customizable that it brings out the personality of a micro-manager, even in people who are usually not micro-managers. It's interesting to see how a tool used every day can shape thinking and behaviour patterns.
I consider JIRA a code smell: if an organization uses it, I probably won't be satisfied working with them. I don't think it's because of anything especially bad with Atlassian (although I was furious when they removed the ability to edit Confluence in raw mode), as that the managers I least want to work for seem especially attracted to it.
Your comment just illuminated that for me and I think you're right. It's the micromanager's dream, but for good managers it doesn't seem to offer enough over the competition to draw them in. The best I've worked with considered PM tools essentially fungible, and therefore weren't likely to invest in 1) paying for the Atlassian suite or 2) the overhead of getting it up and running.
>The best I've worked with considered PM tools essentially fungible
After taking a class and reading up on project management and trying to get more organized about my own projects, it's basically that. People have been able to orchestrate large projects with nothing more than pencil and paper and then typewriter. The best PMs don't need to force a tool choice.
Yes, but to my point, as you scale up you have to take into account people's varying skill levels and styles. If you can manage a huge project with pencil and paper, you'll do fine with Jira, too. If you are good but borderline, the structure Jira offers (and can be shared between teams/cascaded down) can help.
Exactly. Once a product meets the basic requirements, everything else tends to be complication and frippery. That doesn't mean there's not room to innovate on those basics, but it does suggest you focus on nailing them perfectly.
yeah but their lives sucked while doing that. Good tools don't get the job done if you don't know what you're doing but make it a hell of a lot faster if you do.
No it's really not. "Damning with faint praise" is when, say, you've just effusively praised something else, and then say that the alternative is pretty good.
The "least-worst option" means it's not good, but all the alternatives are terrible. That's not damning.
> Damning with faint praise is an English idiom for words that effectively condemn by seeming to offer praise which is too moderate or marginal to be considered praise at all.
Which seems about right to me.
It's like writing an employee a letter of reference, and only saying that they're very punctual - meaning that there's nothing else good about them, other than the bare minimum of bothering to show up at work.
It seems to me that saying it's only good by comparison to how awful everything else is falls into this.
No. If someone asked you to recommend two employees, and you absolutely gushed about one, but then said the other is "always on time" and "reliable worker", etc. that would be damning with faint praise.
Saying that one employee is the least worst employee you have when someone calls you for a reference means they are the best employee. It also means you aren't particularly happy with any of them, but that's just adding a flavor to the sentiment that this employee is your best.
Now, if I asked you to recommend a bunch of project management/issue tracking software suites, and you absolutely floored me with praise for one, but said good but forgettable things about JIRA, that would be be damning with praise.
Coming full circle, saying that JIRA is the least-worst option means it's the best option and you just have an ideal in your head that isn't being met.
I just wanted to tell you that you hit the nail on the head for what I was conveying. I'm not an Atlassian employee, and I'm not out to evangelize Jira. I'm not happy with every decision they've made lately, and I have particular things I feel are mistakes where they delineate between core product/marketplace.
But when I look at the landscape of tools that I've used that compete with or compete with a part of Jira, I just prefer Jira over the rest of them by an not-unsubstantial margin.
That said, Trello was great for a small team bootstrapping a new product without a lot of external dependencies or parallel release cycles and I hope they let them run independently.
"Damning with faint praise" is a pretty subtle English idiom. In my experience, it's only used to refer to an instance where someone is socially obligated to offer praise, e.g. a doctoral adviser writing a reference for their student, who gives such faint praise that they intend the recipient to infer that, were they allowed to, they would have been explicitly critical. Since the comment author in question was under no such obligation, I don't think the idiom applies.
I think in this case it's meant to mean "project management and task tracking tools are basically always hateful, but I find this one the least hateful".
I once, over a beer, told the development team of a ticketing system that I'd never used anything I hated less than theirs, and they all grinned and said that that was high praise to them.
If you believe you can produce such a system that people actually like to use, rather than finding less hateful than the alternatives, I genuinely invite you to try, because I'd love to have such a thing available to me. But I'm afraid I'll remain skeptical until I see it :)
This has been the case for >5 years. Nothing at the enterprise tier is half as good as JIRA (some prefer "least awful") and nothing that's built for small teams gets close to the features needed by large teams.
> I think Trello scales poorly above 5-10 people while Jira is the least-worst option for running a project at any team size.
This my experience as well. What are people using that works so much better than JIRA?
JIRA has problems, but it's far better than any other project tracking/management tool I've tried. Managing projects (especially ones with large or multiple teams) is impossible without tools like this, and I haven't seen anything that makes the process painless.
I agree, we abandoned Trello because of how poorly it handled a team of mixed users. It seemed like all the solutions for our problems had to come from browser plugins, which is just a bad proposition when you need a mix of users of various technical capability.
I don't disagree with this, but very small teams (or sometimes just myself) is exactly what I use Trello for. We use it at home for shared to-do lists, idea boards (way better than Pinterest for us), etc. I realize this doesn't make them much money, but I hope they don't ruin that use case because I haven't found anything I like as well.
Fogbugz seems to really be pushing their cloud stuff though, so I basically ruled it out instantly when I was researching options - it's unacceptable to have to host our code and tracker off-premises on hardware we don't control. Whereas even a small team can run JIRA or GitLab on their own hardware for a very reasonable price.
(I'm the CEO at Fog Creek.) We've updated the on-premise version of FogBugz to be completely in sync with the hosted version, so all the latest features are on both now.
If you're willing to talk publicly, what's the pricing like for a very small, self-hosted group? I'm talking 3 normal users, might scale up to 5 or so.
We're probably too small to be worth your time, but JIRA is offering $10/yr for up to 10 users, $10 more if you want the JIRA Agile features too.
In short: We cost a little bit more, but include features that are separate, add-on products for Jira, and generally software developers are a _lot_ happier using FogBugz. If you want to know more, just drop us a line; don't want to be too spammy here.
Just want to confirm - those prices hold for the self-hosted "On Site" version too, where you don't have to provide any management of the data and hosting?
Unless there are regulatory constraints (can't expect logic there...), I don't understand this attitude. Are all your dev boxes air-gapped? If so, how do the devs use google, stack overflow, etc.? If not, how is your on-prem setup so very different than one that used SaaS?
The attitude is simple - don't give your code, and especially don't give access to your devops repositories to 3rd party companies who simply don't need it.
If a security vulnerability happens on the public Fogzbugs instance, we'd be bitten by it badly in this sort of situation. In our setup, we protect against that by exposing the JIRA webserver and git servers only inside of our private network.
It's not about perfect security, but it does greatly reduce the attack surface when the server isn't even accessible via the internet. I can't prevent anyone who wants to from signing up for the free trial of Fogzbugs and exploiting their publicly running system - even logged-in-only exploits are possible in such a case.
Not to mention the issues with downtime on these cloud providers. My provider has had 1 sizeable, noticeable outage in the last 5 years. It spanned about 20 minutes. Look at a big, popular cloud service like GitHub - they've had several in the past year alone, spanning hours at times.
I find these sorts of compromises where I'm offering my code and server configurations to a 3rd party company (where basically any admin there is free to read it, or anyone who can compromise their admins) to be rather poor. I'd rather keep the blame within my own company and be in control of our data fully rather than having to worry about whether Fogzbugs operations follows proper security precautions, I only have to worry about whether we do.
Call it paranoid if you want, but I think it's a more than reasonable precaution to not just throw your data around to anyone who asks for it. Especially data which could lead to compromise of servers and customer information. I value my customer's information much more than I value any gains from some easy to use cloud service.
Thanks for the detailed reply. The downtime issue is certainly understandable. I hope you're keeping customer data out of DVCS, but it's true that flaws in your code might be more "discoverable" if an attacker had that code. It does introduce another step into the attack, however, to have to hack FogBugz before reading your code and discovering the flaw that hacks your services. You know your threat model better than we do, but I doubt most carders would bother with that...
I'm not too concerned about someone getting the code, reading it and discovering a flaw allowing for exploit. I'm much more concerned about someone being able to modify code that will be pulled onto production systems by build and deployment scripts (not to mention the build and deployment scripts themselves) which would allow direct access without any need to hack anything beyond the external cloud service. Even a disgruntled admin at Fog Creek in this case could do something like this without the need to hack anything.
Does anyone care enough about your product to actually go to the trouble to do that? It seems that in terms of actual risk management, managing an on premise version of everything is mitigation out of scale with the actual risk.
Besides, a disgruntled employee of your company is far more likely to be malicious than a disgruntled employee of some random cloud services company. What would be their motivation? They probably don't care about your code at all -- but your employees -- they certainly might. Has there ever been a case of a disgruntled Github employee hacking a customer company's production code ever in the history of Github? Has there ever in the history of SMEs been a disgruntled employee that harmed his own company? All the time.
So what risk is more realistic to mitigate? The hypothetical disgruntled employee at a vendor that probably has never heard of you or employees sitting right there in the office with you?
> managing an on premise version of everything is mitigation out of scale with the actual risk.
Once you have these services running they're fairly stable and hands-off, especially if you have them firewalled off enough to not have to worry too much about remote exploits. A little bit of docker experience can do the job here, we're small enough that we don't need a fancy high availability configuration or anything, so it keeps things fairly simple.
Of course a disgruntled coworker is a bigger concern, but one which is easier to control than outsiders are. And that's not to mention the many times in the past that I've seen 3rd party companies hacked to do things like steal Bitcoin wallets via their providers. If it's an easy risk to mitigate, may as well do it.
Hmm, code signing might not help us due to some specifics of how we do deployments and builds, but thinking a little more about it - what could help in an even bigger way here is PGP signing at the commit level. Git supports this builtin and recently there have been a few pushes for it's support on services. Probably have to hack together a little custom verification script, but I know of no reason that wouldn't be viable.
This would basically resolve my biggest problems with it I suppose, if used fully and properly. Currently comitting with your SSH key basically resolves this issue in the same way, assuming our internal-restricted server isn't compromised of course.
I'd still be a little uncomfortable putting code on 3rd party servers and having any data there at all for stability reasons, but this does make it more viable. I'll definitely be commit signing everything I have on cloud services from now on.
As someone who frequently works on teams of 10 or less this is exactly what I'm worried about. Trello is a great tool for our needs. I've been in bigger orgs that used JIRA and understand why that made sense, but I'd resent having to use it on a small team.
I used JIRA in very small teams but took great care to configure it sensibly (it took quite a bit of work, I'll give you that). Everyone was happy and even commented on how it made life a lot easier than github issues or whatever other tool they used before.
The biggest problem JIRA has is tons of legacy that nobody needs (like subtasks, a pain in the ass to work with).
Configure the tool properly and it's actually quite nice to use, especially in combination with Confluence for specs.
trello can be used to any kind of project you have in mind, I have my reading list there for example which would be hard to replicate in jira. there are cases were you can use trello and jira for the same puporse and I agreed that in those cases jira wins
