Growth is great, but I've never met a single dev that is excited to use their tools. Management loves their app because they can spit out numbers, and don't care how good or meaningful those number are.
Jira is a painful to use, especially compared to trello. They own trello now, so I hope they don't mess it up.
And to be honest, it's a process tool. Dealing with processes is boring.
Jira is better than bugzilla and trac. And much better than some tools, constructed from manure, from big IT companies and sold for very high price tags.
It's sad to me that they lost momentum. I think they got stuck trying to overcome tech debt and bug fixes and feature requests started to pile up.
From time to time I keep an eye on CommonMark implementations and fantasize about writing an MVP to replicate parts of Trac by composing existing tools. Unfortunately there are like 5 other things I'd rather do with my free time.
I feel Jira is actually a workflow management system disguised as a ticketing system. It is a complex product and their pricing is shit expensive but I haven't come across anything more powerful.
IMHO If you are a small startup and can be self disciplined, you don't need Jira. It is more for enterprise setup where accountability/responsibility has to be generally enforced.
I think this is some kind of natural law: any sufficiently old enterprise system tends towards becoming an ad-hoc, bug-ridden, poorly specified workflow engine.
It's only "good for enterprises" insofar as management gets a boner over the reports it issues and the level of detail it lets you drill down to.
Those reports are not generally being used to make sensible decisions, but they make management feel more in the know and in control and thats what really drives sales.
Not to mention their UX is horrendous. You never hear people wanting to copy their UX. With the size of their company they should be able to produce better.
Just about every web-based Java project I've came across carries a certain persona of UX being terrible to navigate, slow to use and all around a negative experience once you try something that just works.
Jenkins comes to mind, Jira of course, and just about any other Java project's website still looks like it is from the 90s.
Maybe that's because they actually are from the 90's? Well, not 90's, but early 00's. And they target the enterprise market.
Also, all the big internet companies use Java, basically. You're using Google, Amazon, Twitter, Netflix, etc. products and you're using Java. Do you also hate those? :)
Furthermore, Java is mostly server side at this point so I'm not sure your UI complaint is really valid...
The problem isn't Java per se but that the UI code becomes fossilized and nobody wants to put in the effort to update it. The same issue happened with Perl and now (to a lesser extent) Rails sites.
> Jira is a painful to use, especially compared to trello.
If you're using JIRA for stuff that Trello works for, then sure.
What JIRA does and does exceptionally well: grows with your organisation. You can start using JIRA for a simple ticketing system with 3 devs, then continue using it through 100x growth and still use it with multiple product teams, multiple development teams, overlapping projects, CI, code review, wikis, reporting tools, and so on.
If you think that all these tools and sophistication is bullshit, then that's a different conversation -- but a non-negligible number of smart people think that these integrations worth a lot.
JIRA is like Excel or Word -- 80% of people use only 20% of the functionality (or less), but it's a different 20% for all of them. And it's really-really painful to realize that Trello/GH Issues/etc. works great with a slick UI, except that it can't do that single stuff you'd really need because of your special situation.
>If you think that all these tools and sophistication is bullshit, then that's a different conversation -- but a non-negligible number of smart people think that these integrations worth a lot.
If you can point me towards someplace visible that is using these tools well, I'm more than happy to be wrong. Every time I've seen them used, they're more like rorschach number generators for management, so I have naturally assumed that my experiences are the normal. That is, of course, a fallacy, so if you can point me to such a paragon of use, I'll be more than happy to check it out.
You seem to be talking about JIRA reports. JIRA != Trello + fancy reports.
The strength of JIRA is that if your company suddenly needs a different development flow (whatever it is -- new tooling, new workflow, more teams, awkward regulatory requirements etc.) then you can stay with JIRA because whatever you want to do will be possible with JIRA.
(Uh, I sound like an Atlassian shill, even though I dislike the lagginess of their UI and also how they handle Bitbucket. :) )
> The strength of JIRA is that if your company suddenly needs a different development flow (whatever it is -- new tooling, new workflow, more teams, awkward regulatory requirements etc.) then you can stay with JIRA because whatever you want to do will be possible with JIRA.
This actually seems to me to be the biggest problem with JIRA... JIRA allows for the creation of arcane processes that very easily become burdensome because JIRA is very loose in its opinions. And, on top of that, the management of that process also often becomes a burden for the same reason...
And you're also stuck carrying around all the features you don't use...
You can also build flexible, low-overhead workflows using JIRA. The key is to keep managers out of the admin section, make sure the dev team is in full control, and tend towards saying "no" whenever anyone asks for changes to the workflow.
I think anecdotally that may work, but I'm not convinced that dev teams are that much better than "managers" are at creating or managing process (nor are they often very interested in doing it)...
But I think this does get to the core issue with JIRA. Whether you "like" JIRA or not is more a reflection of your organization than it is a reflection of JIRA as a tool.
Just anecdotally I can confirm that different development and product teams work good with JIRA and Confluence in conjunction.
The agency I work at uses these tools together with ovur clients, as well as internally on different levels.
We have an internal project were we are just using tasks, subtasks with 3 states in a team of 9 in three to four locations. And we have a client, being served with about 100 people in different teams working on multiple projects, spanning multiple locations. Here we use the same tool. In one case with just a basic setup. One a 'little bit' more elaborate and customized...
There are places where the incoming work is pretty high volume...so you need a "ticket" system just to make sure it's all accounted for. Jira isn't perfect, but I can't tell if you just generally object to tracking work, or if the particular environment you're in just doesn't need that sort of thing.
And, of course, it's configurable, so any local installation of Jira can be tweaked in such a way that it's a pain in the ass...or not.
I've worked places where there was a high amount of incoming work, and no tracking, and it wasn't healthy. Lots of "squeakiest wheel", "who is working on this?" and other issues.
> but a non-negligible number of smart people think that these integrations are worth a lot
Just throwing something out there... But I wonder what the spread of these "smart" people is across "development" and "management"? The parent comment seems related to this...
> JIRA is like Excel or Word -- 80% of people use only 20% of the functionality (or less), but it's a different 20% for all of them. And it's really-really painful to realize that Trello/GH Issues/etc. works great with a slick UI, except that it can't do that single stuff you'd really need because of your special situation.
Also, just throwing something else out there... But I wonder, at what point, do we stop building tools that can work for 99% of the use cases and start actually having opinions on which specific use cases are "good" or should be encouraged? Because, like some of the other comments have said, a lot of those workflows that "only use 20% of the functionality" aren't exactly appealing.
Also, just throwing something else out there... But I wonder, at what point, do we stop building tools that can work for 99% of the use cases and start actually having opinions on which specific use cases are "good" or should be encouraged? Because, like some of the other comments have said, a lot of those workflows that "only use 20% of the functionality" aren't exactly appealin
The "tool" doesn't need to be overly "opinionated" just like a programming language, I want a tool to be flexible. It's my responsibility as the architect to constrain the tool/language for my environment.
I think broadly this metaphor works. But you, as an architect, have a breadth (probably) of experience to draw from that dictates how you work in that environment. I feel safe saying that those that are creating or managing processes in the JIRA environment often don't have the equivalent experience (or they have experience only in other equally dysfunctional uses of JIRA). And that JIRA doesn't exactly enforce good habits on its own (a la JavaScript, for example).
Indeed, JIRA is a necessary evil. There is nothing out there with the flexibility of JIRA, and a plugin ecosystem. The user interface is driven by its fully-configurable nature and almost by definition it will suck.
Now, if there was a way to grow its user interface along with the organization's growth, it would be fantastic.
I'd argue that we're stretching a bit with the word "need" here. Are we still at the point where every software development team has to come up with their own special process?
I feel like, as an industry, we should be moving beyond that at some point.
> Growth is great, but I've never met a single dev that is excited to use their tools.
I've seen one dev excited - the one who tested other tools and picked Jira because it checked off on all the "features" needed. It really did handle the arcane and complicated workflow we had. But besides that few liked it, though it was a mix of hating the slow and unresponsive UI and hating the arcane process.
I think this post speaks to a lot of the issues I see not just with JIRA, but with enterprise tools in general.
Instead of adopting a sound process, customers will take an overly complicated business process and make the tool conform to this process. And please note that in this cases how you manage your code workflow is, in fact, the business process.
Any tool will struggle - often it's the process that's cumbersome and not the tools.
My main gripe with Atlassian products is the execution - the ideas behind the products are usually sound, it's just pretty clunky to use.
For me, I'd love to have a flexible-enough tool for small to medium sized orgs that encourages a modern lightweight process and discourages ad-hoc process sillyness. Sometimes having a tool gently encourage better practices among all participants is a useful thing.
I love JIRA from a tech leadership perspective. It's very adaptable to different situations even if configuration isn't straightforward. Once you have a good workflow, it's great for devs and managers. The value for managers really should not be understated here. It's great for devs to have a simple ticket management system to help the flow of work, but being able to show measurable progress against priorities to management is absolutely to everyone's benefit.
>The value for managers really should not be understated here.
Can you expand on that? I've never seen a manager use it well. They use it to generate numbers for their reports for the people they report to, and it doesn't tend to matter what those numbers or reports actually represent. For example, it's very easy for process to make velocity numbers complete hogwash.
Basically, as far as I can tell, it's great and being able to tell you what you want to hear, and not very good at providing usable insights that increases productivity, but people don't notice because they're hearing what they want to hear.
Well, once you're in that situation, you've already lost. Scrum is worthless if you haven't set he appropriate expectations with stakeholders at the outset. If you get them to understand definitions of Ready and Done as well as quality-first approach and being flexible on scope, then the backlog gives them all the information they need to understand what is being worked on and when. I've seen it done correctly a few times and I've even seen behemoth organizations get behind it and get a ton of value out of it.
For my money, the #1 benefit to scrum is improved visibility to stakeholders and any productivity gains to the dev are the result of them being able to work on things in the correct priority order due mainly to benefit #1.
I actually like JIRA, but I'm also an admin in it and have taken ownership of the workflow (and really push back on any change requests to it).
One thing I definitely don't have is any managers living in it. It has all kinds of (useless, IMHO) reports it can spit out, but we don't spit them out, other one for time tracking some particularly-tagged issues (for the SR&ED tax credit program).
What is really awesome though is looking back through issues (and in general, JQL). For example, finding any re-opened bugs:
type = bug and (status changed to reopened after 2017-01-01) and project in (PROD1, PROD2)
or building release notes (and excluding bugs that were found internally only):
project = PROD1 and fixVersion = "2.0" and affectsVersion != "2.0"
We generally just look at these in the UI (though I suppose you could consider this a 'report' of sorts).
This is very anecdotal. To see JIRA used well, you need both management which is willing to invest the time and effort necessary to learn the ins and outs of configuring JIRA, as well as competent and flexible stewardship by the admin team to enable desired configuration in a way which fits in with the rest of the instance and doesn't pollute it. If you pay attention to recent JIRA releases, Atlassian is trying to enable management to make the changes it wants to make without resulting in global pollution, but either way, you still need management to personally buy in.
I've seen everything from managers who refuse to customize workflows beyond "todo-in progress-done" to managers who use post-it notes on the wall for their "real" agile board, and then copy the changes by hand into JIRA issues to communicate status up the ladder. If your company's management isn't buying in, your company needs to either replace the managers or replace the tool, instead of trying to fit round pegs into square holes.
As much as I'm a hesitant user of JIRA, there is little out there that can grow with the complexity of a project and organization like it has.
Other tools, fogbugz, trello, etc are very good at what they do.
Invariably though when you get enough projects that are complex enough (not always big), JIRA has been the only thing that could take a bite out of managing the details like few others.
JIRA also can be greatly simplified to use but most users don't do this. The JIRA core offering is what I recommend to folks. JIRA is heavier for dealing with heavier projects.
On the flip side. Having a search engine of every issue and decision, be it design, system, implementation, roll out ticket for every project in a company is second to none.
I recently assisted a client in their systems design and growth from from 0 to 50m revenue in 4 years. It feels strange and wondeful to have every decision made in one searchable place, on one time line for every major piece of software or system implemented for them.
The features you are talking about, like having a search engine, are in just about every product that could exist in this arena. Have you used GitLab and GitHub before for issue and project tracking? What about Phabricator?
Complex projects, complete with their integrated support, roadmapping, sprint management invariably have a few order magnitude higher level of complexity and management. There are few tools that truly do the above well, or bearably competently.
Most start from scratch projects can be nicely managed in Trello et al.
Generic search alone isn't the feature, or the benefit. None of those options listed have a deep enough search. GitLab and GitHub aren't a project manager - projects that are manageable in Git* likely aren't complex, or enterprise grade.
I have tried nearly every product in this arena as well over 20 yrs of dev in different types and sizes of projects. JIRA begrudgingly is my neccesary evil. I hear nice things about Pivotal Tracker as well, just didn't reach my sphere of folks when I was looking.
> It feels strange and wondeful to have every decision made in one searchable place, on one time line for every major piece of software or system implemented for them.
I can see the appeal of that. That is a killer feature for me. My team currently runs what I find to be a pretty lean and clean workflow using Trello, Github (for source control and issues), and Wikimedia for documentation. (Oh, and can't forget Outlook for release scheduling.) Having all of that in one place would make life easier.
On the other hand, not having a monolithic service handling everything has forced us to pay attention to our workflows and practices and keep them sharp.
But the team is small. If we grew or had to manage more projects across multiple teams, this would be really valuable.
Totally killer feature. I spent about 4 months trimming down JIRA to a custom workflow that matched what we used in Fogbugz for a decade. I now have a simple workflow for very basic projects that spins up a trello-ish kanban, and for heavier stuff I can switch the workflow to our full grade setup. JIRA recently has included JIRA Agile with the Trello/Kanban right into the project, and it isn't half bad.
I used FogBugz for almost a decade until the most complex projects I was working on dragged me into JIRA. I miss FogBugz' email first interface.
My Current stack is JIRA/Confluence on demand, the integration in the WIKI is simply too good to overlook. For product roadmapping I use Aha.io integrated into JIRA.. it's so far a more capable product than JIRA Portfolio, JIRA portfolio doesn't go high level enough. Harvest in the mix for easy time tracking.
The investment of time in integrating projects between Aha and JIRA so far has been a big payoff. We can literally start noodling with ideas high level, and as soon as those ideas cross the line into an epic, we have the sprint ready to go and automatically created in JIRA.
While it wasn't as smooth, the incredible detail we can manage things that need it, while leaving other simple items to hop through the steps that aren't needed was invaluable.
Have you tried managing 1000 tickets in Trello? Jira also offers decent API so you can streamline it a bit. Although I’ve gotten used to their cloud ui where it’s pretty easy to manage. I do wish response was faster though
I can understand why management would want to choose Atlassian.
* The idea of the "Atlassian Ecosystem", in that buying more of their services seems to work better.
* On-premise for most of their tools
* Pricing. For example, Bitbucket Server - $26,400 for 500-1000 users /year [1]. GitHub Enterprise - $2,500 per 10 users / year [2]. Self-hosted GitLab - $39 or $199 per user / year (Starter compared to Enterprise Edition Premium package) [3]. If at a 1000 users, that is $26,400 compared to $250,000 or $39,000/$200,000.
* "Other big companies use them"
* "Reporting and metrics"
* "There is a plugin for that"
But, I and most of the other developers I have worked with hate every single Atlassian product we use. JIRA eventually turns into a micromanagement tool with all of the customization people think they want.
People seem to think that because it is customizable, it will solve their problems. It always seems to take up more time and resources to try and bend their tools to do anything useful than it is to just say, "well, I guess we don't really need that".
I hear this a lot, but I'd love to hear what people prefer better. Also, I don't get the argument that JIRA is difficult to use. I can open a bug, fill out a few fields, assign it to someone, etc. easy peasy. Almost all the other tools I hear as substitutes are decent only when you have a few devs on the team.
Personally, I don't mind JIRA and the Atlassian toolset as they are so much better than what we used to use in the old days.
I feel like JIRA was just a configurable workflow tool at a time when all the processes around software development were still being defined/standardized. It worked well for it's era because people could get it to do whatever they felt was perfect fit for them, but overtime I feel like it's broken down for much the same reason that people prefer to buy a SaaS product that has 95% of their needs out of the box.
Processes (agile) and UIs (kanban) have been much more standardized in software project management and only now does it seem like some companies are coming up to give you that 90% out of the book with 10% the overhead/ management. Pivotal Tracker came close.. Clubhouse.io is the one I've seen doing it best.
Pivotal Tracker has been around for a fair while now; it's usually compared to JIRA.
They have quite different DNA. Tracker grew out of Pivotal Labs and it is mostly molded to how Labs and R&D teams do their daily and weekly work. To me it seemed constricted and limited until I came to work at Pivotal; now it makes sense.
I've used Pivotal Tracker and I think it's great for small teams, but I can not see a big company with 500+ users using it. JIRA is better for ticket tracking, issue linking, cloning, reporting, integration with Bitbucket/Github branches, user permissions, build system integrations, burndown charts, analytics, media services support, and not to mention the ecosystem around JIRA is just huge.
Disclosure: I'm an Atlassian employee, but I had these opinions before I started.
> Jira is a painful to use, especially compared to trello
Have never been able to use trello effectively with any clients. It's simply too open-ended on its own. "Issue trackers" (like Jira) have some semblance of workflow predefined, and act as a decent guide for people who are not "project managers" to still bring some degree of order/structure, with the benefit that that structure was actually defined by someone else who thought about data/structure/flow/etc.
we just moved from jira hosted to jira cloud and it is, shockingly, worse! As a user I've always hated JIRA and as an admin it is shockingly bad. There must be some alternatives that are still viable.
There are some actions in Asana, like tags and projects, which are immediate and inline, often with a hotkey. In jira, it could literally be 4 full screens.
Other examples include filtering and search. Google has raised the bar so high in both gmail and core search for how a query should work. Jira says fuck you here is JQL, and it isn't at all obvious why.
Yes, search is really bad. We now have a corporation wide JIRA and searches return results from all 100+ projects. If I want to search in my project I have to use JQL.
Personally i find Redmine to be pretty horrible (and i have to use it daily). It's slow and it doesn't have a working search feature. Maybe Mantis is better these days...
May I suggest a crazy idea? Ditch it and just see what happens.
We are a large organization, and had an end of year crunch so naturally when you need to pinch the absolute most productivity out of your workers, typically process is the first thing that goes.
We just had our most productive 2 week sprint in over a year, by a mile. Instead of Jira, we busted out the dusty whiteboard, and used this amazing technology called an expo marker to write down what we were working on and who was working on what. It had amazing visibility too -- our manager could stop by at any time and see with his own eyes what we were working on -- all without having to log in! The best part? We got to ditch the meeting to plan the planning, the planning to plan the week, and the retro to go over the week to start of the next week's meeting to plan the planning. We got back like two entire days, and we didn't have any 9:00 AM context switches when most of us were in the zone already having to give a benign update that could have just been communicated via slack!
Some of this is sarcasm and I do understand why managers and leaders reach for Jira, but seriously: Why did we stop using the whiteboard. If you need visibility into this crap, hire someone to do that. You have analysts for your business, why not have an analyst for your tech? It doesn't make us more productive.
The number of photos of whiteboards I've taken over the years beg to differ. Point 3 is certainly valid. Whiteboards definitely don't work for remote teams.
Because whiteboards aren't visible outside the rooms they're in, and they don't save histories of what was written on them in the past. If your org is scaling beyond a single geographical location, then you need some kind of system to communicate status to stakeholders elsewhere. Email and Slack are nowhere good enough for that; a ticketing system is absolutely vital.
> The thing that made the product challenging to learn was what developers loved most about it—that it did everything needed for issue tracking, and they could customize it to work precisely the way they needed it to for their specific teams and projects.
I don't believe this. There were plenty of competing Open Source tools out with the same problems. I hated every single one of them and so did other developers I know. Perhaps developers preferred Jira because the management could be told they'd have to pay a qualified contractor for customization instead of torturing the developers with that kind of work?
Someone observed a very long time ago that you can only count on devs to put the information into the ticketing system that is useful for their day to day work.
I've only had luck with management (analysis and planning) of ticketing systems when we treat this observation as law. Either you measure what you have the data to measure, or you convince the developers that maintaining some part of the data is useful to them on a daily basis. The third leg of that stool is realizing that graphs and trends are for asking better questions, not for making decisions.
Everything else comes down to a weak appeal to ethics. The problem is that a lot of devs either have or think they have a richer sense of ethics (not necessarily better, but more considered) than the people who want the data. So these appeals come across as tone deaf.
I wrote and used a minimalistic one to save me time: plain e-mails to people with "[t]" in the subject got put in a database, recipients got modified e-mails with URLs to a web interface in the body (in addition to the original e-mail). When the task was completed, you only needed to click on one link in the web interface (or in the e-mail) and the original sender would get a confirmation by e-mail (i.e. you didn't need to write that e-mail yourself). The web interface provided an overview of open tickets and statistics. Later, comments, re-assigning tickets, priorities and other stuff was added.
This was used for > 10 years (for a few 10000 tickets) AFAIR until it got replaced by Jira. It worked well and was accepted (or so it seemed) because it didn't really interfere with the typical way of doing things till then (e-mails) and offered minimalistic features on top.
Is it developers who are pushing for Jira? I've always seen it as a management-driven thing, effectively cementing the dominance of management methodologies like Scrum.
I’ve encountered developers who appear to advocate for JIRA. Pretty sure it’s not driven by “this product is a delight to use”, though, but rather a badge of honour saying “look, we’re professionals doing things properly.”
Like the sibling comment, my own encounters with it have made me think more of the deli counter...
>but rather a badge of honour saying “look, we’re professionals doing things properly.”
I don't doubt that this is the case. I worry that this begins to approach a "cargo cult" manner of thinking about development.
I can't help but wonder if this trend favours younger developers, who may not remember the days before Scrum became such a widely-practiced management style.
>Like the sibling comment, my own encounters with it have made me think more of the deli counter...
No doubt. Instead of being judged by lines of code, the deli worker now has to concern themselves with things like "velocity" (in which case, Jira has become a prime tool).
This is the lie the industry keeps telling itself, especially in print.
Vendors come in and bullshit your bosses and the purchasing authority about how awesome their tools are and all the things it can do.
By the time the developers catch wind of it the check has already cleared, and they -have- to use this tool because someone with firing authority paid for it and you're not going to get away with embarrassing them by calling them on their bullshit (young me tried, young me failed).
I'm not aware of any development team that consciously picked Atlassian. Atlassian gets picked for them. Their success is in selling to the management chain, not in being a good product. Because they aren't (but then neither are many of their commercial competitors).
Some facts in the article that was linked are definitely not correct. Fogbugz was out there before JIRA. Spolsky wrote about JIRA multiple times, yet the article never mentions it.
So what is this site anyways? There's no About page, no contact, no ownership information, no author, nothing. Looks like an advertisement to me.
In the eary days, Jira was an awesome bug tracker (free for OSS), compared to Bugzilla or Trac. But they focused on adding lots of features without much thought on the overall user experience. Their latest UI revamp only made things worse.
Somehow, they managed to accumulate the negatives of a flexible product (resulting in poor/incoherent UX) and the negatives of rigid assumptions regarding workflows (try modelling staggered deployments in different datacenters/environments spanning multiple sprints... good luck!).
Going forward, I expect Atlassian to cater to rigid organizations and neglect those who design their own processes (whether lightweight ad-hoc or complex custom ones that don't fit what Atlassian Sales can understand).
I also "love" how they re-designed the issue UI. What do you need in an issue? Obviously, issue description. Now even on largest monitors issue description starts below the fold. Everything else is taken up by nice crisp white-space-separated "important" information: the sprint name, the epic link, number of hours projected, who it is assigned to, etc. etc.
how many points is this outage going to be to fix? we'll need to bring it up to the project committee to see if we can allocate it out of the next sprint
"Points" the gateway drug of JIRA. It's honestly the most difficult/simple concept to understand, since it's all about "don't think intuitively, because in JIRA that's the wrong way to think."
There is an enormous amount of hate directed at JIRA that is a side effect of customizations created by admins. People abuse the customizability and their own internal users suffer the consequences.
That's actually one of the few non-default things on that instance. Because it's a public issue tracker (which few companies outside Atlassian are willing to do to themselves), some comments by employees are hidden to the outside world.
It appears the issue in question was commented on 1 year, 13 weeks ago. But the comment isn't visible to the public, thus the "no comments yet" message.
I recently joined a company that used Jira and the UX is worse than any web app I can remember. And I'm old. Jira is an excruciatingly slow and infinitely confusing abstraction and I have no idea what problem it solves better than competitors in 2018.
I showed the CTO and CEO ZenHub and we're off to the races.
Yes, I can relate to that. Jira is extremely slow and counter intuitive to use. So much that I believe it will create friction within an organization, because people will try to avoid using it. Weird filtering system, weird keyboard shortcuts, long loading times for everything. I really don't understand why performance is not the top priority @Atlassian. A very bad example of workmanship and I don't care how well it integrates with XYZ.
Not to mention the workflows are crack for anyone looking to make themselves powerful and essential without doing any real work. I was in an organization where many meetings were spent begging the workflow czar to make minor modifications to prevent tickets getting stuck in states where the people responsible for them couldn't advance the workflow. At one point we got lectured because some managers (in a major act of rebellion) got in the habit of abandoning and re-creating tickets whenever they hit problems. In another incident, someone coopted an industrial plotter to print out the entire software development ticket workflow to embarrass the workflow czar into stopping his shenanigans, but it didn't work.
The biggest problem with JIRA is management. Workflow hell, death by a thousand fields, shiny addons, etc.
It’s probably inevitable but a policy requiring strong justification for and regular review of any “aftermarket” changes might slow down or reverse the descent. The closer it is to vanilla the easier it is for (almost) everyone. Managers and workflow czars (nice one btw) of course would be inconvenienced but they should be comfortable making really strong justifications for making the lives of developers harder just to make their reporting smoother.
I attended a talk by a Netflix employee where they talked about a sort of organizational immune system to aggressively prune bureaucracy and policy by forcing it’s existence to be regularly justified. It helped me connect the dots and realize that allowing heavy customization was as much a poison as it was a boon.
I'm not even sure why is performance such an issue in the first place. It's not like 50 users can cause a lot of traffic. They have time to literally pre-generate all the views that could change after every action, between the times a user actually makes any change. I get that the data behind the views is complex, but having to wait multiple second for fairly trivial pages is crazy.
If ZenHub works for your team, sweet. If the business is operating at a scale that ZenHub can serve adequately, you're probably not an ideal customer of JIRA. There's a tipping point along two different axes where JIRA becomes worthwhile.
One axis is number of people actively using the tracker for a single project — I personally think that threshold is around 50 people^1. Another is workflow complexity — very few tools are as capable of mapping business processes to software as JIRA^2.
1. Careful, there's another threshold at which JIRA becomes painfully slow. At that point you either move to something that's less adequate in nearly-every way but scales or you start splitting JIRA instances by department or project.
2. Careful here as well! Poorly created JIRA workflows are probably _the_ #1 reason people hate using it. Users learn a highly customized JIRA workflow and think it's absolutely bonkers that Atlassian did this to them, when really it's their company's customizations that are causing the pain.
They have JIRA Data Center now which is far from perfect but helps with the scalability issues. It’s costs quite a lot though. DB is typically the bottleneck after that, especially since they don’t officially support any DB clustering. Postgres is their best supported DB (it’s what they use in production themselves) so maybe as native Postgres clustering matures we’ll see support for that.
The 'threshold where JIRA becomes painfully slow' for our team of 5 was on day one, when we had to wait multiple seconds for an issue to load in the browser.
I disagree entirely, Atlassian is moving to accomodate both lightweight teams and rigid organisations.
If you look at the most recent changes to Jira, like the Agility boards announced at Summit, it’s about starting from as much flexibility as Trello and expanding to as much power as standard Jira (if you need/want it).
Disclaimer: ex-PM on Agility boards, no longer at Atlassian, opinions are my own.
They sure did outsourcing well, I wonder how has that contributed to their success. There's a big dev shop in Poland maintaining and developing large bits of their core offering - Spartez.
Most of their dev is done Sydney and SF. They also have offices in Austin and NY now.
Spartez has obviously been a great partnership but "large bits of their core offering" is inaccurate. That's not to deminish the efforts of the people involved. It's just materially untrue for most values of "large" and "core".
The amazing part Jira is most basic tool many of us use daily . As evidenced by huge number of posts here people really hate it yet there is no good alternative. So instead of uber for pancakes maybe someone will be inspired to build one :)
The more interesting question is "Who can beat Atlassian in productivity market?" What properties this product should have? What Atlassian weaknesses should it attack?
I only wish that companies also accepted that you need a ton of consultant time before you can actually use it like it's known for SAP. The out-of-the-box experience of JIRA is pretty poor.
I came for this comment. The big difference between JIRA and SAP is that SAP is a "batteries-included + kitchen sink" package (which tends to require molding business processes around it). My problem w/ JIRA is that anything beyond the simplest workflows/BPM requires purchasing a ton of paid plugins that tend to be abandoned over time. Atlassian knows what users want but they are dog-slow at bringing them to fruition.
Most comments revolve around JIRA as an issue tracker. I think those miss the point. Atlassian products are never best in any given category (in my opinion); however, they all integrate easily and (almost) out of the box. Choosing JIRA over another product might not be meaningful, but you need source control, chat, build servers, etc. Having them play nicely together without fiddling with tricky settings is a huge benefit.
> What if you have a product, that integrates best tools in any given category? Slack, GitHub, etc? Can this solution beat Jira?
No, it can't. Atlassian's tooling is used by large teams. It doesn't make sense in a small team environment. In a large team of say a dozen people, can you imagine managing accounts/permission/access to a dozen services? That's over 144 accounts, plus billing, plus all the other stuff needed to make everything play together. Nobody wants that headache.
That's just the tip of the iceberg too. Atlassian already plays well with Github and other services. So you can have your cake and eat it too.
> Atlassian already plays well with Github and other services. So you can have your cake and eat it too.
This is really the benefit of Atlassians wide product funnel at the top. JIRA might be the Worst Thing Ever, but it can be configured to needs and integrates well with most-everything. In a lot of Enterprise scenarios the most win/win solution can be using JIRA as your default and master data while teams and projects are using integrated too stacks.
That way your suits can have standard tooling across the board, your sensitive issues are all registered in an on-prem installation, and your dev teams are free to find The Right Thing for them.
Atlassian/JIRA is a platform as much as a product. With its integration story and plugin market you don't need to swallow it whole parcel, and it's easily an industry leader in that regard.
This has been done for the past 30 years. Grouped and explicit permissions is a thing. Not sure why this would be any different in an integrated environment.
Absolutely, however you are not picking the best tools IMO. I would look at GitLab, which has stronger project management and issue tracking integration (as well as a free self-hosted version). Another solution is to evaluate Phabricator as it has a stronger feature-set in some areas.
GitLab Omnibus has Mattermost integration, but you could also look at Rocket.Chat (and in all honesty Discord is a kickass free alternative to Slack).
This is a great example of why Atlasssian is a compelling option - what's 'Best' in each category? Getting a single (supported) license that you know will work is much simpler for all.
Thanks for mentioning us. In my opinion the primary difference between Atlassian and GitLab is that they have separate applications that integrate while we have a single application https://about.gitlab.com/direction/#single-application
I wish they'd merge with Slack. There's been virtually no improvements to HipChat in more than 3 years now aside from some tagged on, half-usable features.
Funny, they don't mention Bamboo CI. But probably for the better since there are tons of better tools out there like CircleCI, Shippable, and even Jenkins.
Bamboo is sheer madness. Used it almost once an hour for 3 years and it felt like I was back to square one each time. I could never really learn the UI.
One thing to keep in mind is that Bamboo was first released in 2007. Less than a year after AWS was initially launched and well before things like Travis or CircleCI existed to make the cloud side of the CI equation obvious.
I agree that there are better services if you don't mind running on other people's infra. Behind the firewall Jenkins I'm not sure about, I haven't tried it in ages.
2016 I was almost 2 years into using bamboo heavily. End of 2016 there was still a feature/ticket open with them requesting an http/s target for build notifications... Really, no option to notify an endpoint when a build finished...
I've developed against JIRA and used JIRA pretty heavily at several companies now. JIRA is a really nice product, but one's experience with it heavily depends on who "owns" it.
Finally, someone makes _the_ point in a thread about JIRA.
JIRA's most powerful feature is that it affords for mapping businesses processes onto software. This is incredibly compelling to enterprise customers. Software that enforces workflows, procedures and requirements can be an incredible lever and JIRA's price point makes build vs buy decisions an absolute no-brainer.
The down side for the true end-users, those who actually use the software day-to-day, is that most business processes are awful.
If your experience is the hellish existence that I see strolled about on threads where JIRA comes up, I can say with near absolute confidence that it's because of one of three things:
* Your admin(s) set it up once and hasn't bothered to iterate on those workflows.
* The business mapped their autonomy stripping processes onto JIRA intentionally. I'd guess that most of your work experience is similar. Process stifled nonsense.
* You're on an instance that is serving too many people with too few resources. Shard your instances folks, the money for extra licenses is wildly cheaper than the human time you're wasting waiting for stuff to load.
Exactly. Conway’s Law doesn’t just apply to software you produce but also how you configure things like JIRA. If JIRA sucks chances are you’re probably looking at a reflection of your organization’s dysfunction.
What have you developed for jira? Plugins? What type of functionality? Do you have any advice for someone desiring to develop a plugin and sell a jira plugin?
Lots of automation. Creating/managing issues and tying them back into other biz processes, i.e. significantly worse tools (think: ServiceNow). Easier tools for managing issues from the command line. That sort of thing.
With bugzilla everyone can understand what tasks
exist. With jira you need a manager for what. Control of the information flow is the basics of geek politics.
I hear this take a lot, but it really fails at some basic usability stuff. For example, the way it does code blocks breaks all the time, especially if the content has curly braces. As, you know, many many languages do.
I think we can just admit to ourselves that JIRA is bad. It’s ok to say it.
There is obviously more to it than that, but it was my thought way back when.
I interviewed with Mike and Scott when there didn't seem to be many other people involved. A few days later the company I worked for started the process of getting acquired.
I tossed up what I thought my share options might be worth against two guys who seemed to be just out of uni with a bug tracker.
I called them back and said I'd stay where I was. My options were worth nothing. Joke was on me big time!
Later on lots of my dev team ended up working for Atlassian and I thought it might be time to check it out again. I went for an interview and was told I wasn't smart enough, despite the fact I'd already mentored a bunch of their devs.
At least they gave me an interview. Most places don't 'cause I don't have the book learning to get past HR.
What differentiates JIRA from other issue trackers is that it's very popular with Chip/Asic companies; they have support for all chip design phases, which other issue trackers lack.
in other words, they found a market need others ignored, and they served it.
Where can I read more about this? Would you kindly refer me to some web page or anything ? Also, do you know which ASIC/ Chip / VLSI companies use JIRA?
I work at another ASIC company (Storage Industry) and we use JIRA as main issue tracker; JIRA feels very tailored for ASIC, at least the version at our company
> While a lot of companies make acquisitions, most don’t execute well on integration.
I have a theory that much of the success of web-based companies isn't due to the internet's reach itself, but because they can actually harness programming to business. Make something happen; check for something; modify everything. Of course, there's always problems with programming but it's so much easier than doing it any other way.
But traditional businesses cannot reap these benefits, because they cannot make IT central. They can't be IT first. And they lack the talent and experience to handle all the problems of programming. Therefore, it is the new web-based companies that know what they are doing (with programming) that win this.
The quote above is a great example: it's hard to integrate acquired businesses, they usually just become a messy "conglomerate". What if you could actually integrate other products and services into your products and services? With programming, it is possible, whereas it wasn't really before.
There are still problems - and other commemts highlight how the UI has suffered. Indeed, enlarging a codebase inevitably has much in common with a messy "conglomerate". But it's so much easier than doing it in any other way than with programs (i.e. traditional businesses).
(Atlassian's products also help other businesses run on programs, but that's not my focus here).
As an unhappy Bitbucket user, I have my fingers crossed for better Github enterprise pricing (does not scale for dev agencies with many repos), but mostly for AWS Code Commit.
It's somewhat scary the breadth that AWS has in their ecosystem now; however, Bitbucket is wrought with issues like:
- no large file collapsing, i.e. lock files
- random downtimes ( I wonder if they actually meet their SLA )
- feature requests on boards where Atlassian members ask why x is needed, followed by a slew of +1's, to only see someone ask 3 years later, "where is this at?"
I'm a jaded Atlassian user who believes they buy competition and then stagnant the product's evolution.
I've cruised by it a couple of times, but my workplace is already bought in on AWS. Code Commit has some nice integrations for CI / CD whereas I can't really make the case for Gitlab other than, "I like it more"
Positioning it more like:
- It will save us X amount of time on average
- Give us better security through IAM
- Reduces fragmentation across org software
sells a lot better to people with credit cards than, "I like it more"
> I'm a jaded Atlassian user who believes they buy competition and then stagnant the product's evolution.
What product do you think Atlassian has bought to stifle it's evolution? Bitbucket specifically was a product with 50k users and Atlassian has grown it to Millions. Buying a competitor just to let the product stagnate and die makes rarely sense in business.
Trello is what came to mind at first. It made more sense to buy it, rather than it being competition to Jira.
Hipchat could have easily taken the space that Slack exists in. Lack of product vision and resources dedicated to the project ultimately led a non-existent competitor to own the entire market.
I’m certain no one at Atlassian wants to stifle Trello. Trello is Atlassian’s Instagram.
By the way did you see Trello is now part of Bitbucket as a default?
What exactly was HipChat competing with in the Atlassian portfolio when it was acquired? Nothing. HipChat was three people when it was acquired. It was over 100 not long after. That space grew so fast that you could argue maybe Atlassian should have put 200 on it. Regardless, it got the biggest investment of any group chat tool in the game at that time. Slack did an amazing job in the viral growth front. Credit to them. Atlassian is beefing up HipChat for enterprise/BTF and launched Stride for everyone with an email address and a need for something more focused than slack.
Having worked extensively with JIRA in the past, I will say that whoever designed it had to have done it with clear intention.
JIRA has an uncanny way of attracting to it a very specific (and valuable) person inside organizations.
I mean the person who is obsessed with the creation and quantification of knowledge worker processes that are subtly complex. This complexity naturally gives plenty of fodder and massive surface area for engagement and features —- one can spend hours tweaking JIRA workflows, running reports, and playing with the query builder. And we all know that once a user is engaged past a few days you’ve got them, almost like a kind of pair bonding. They have bonded with your software, and they’ll be forced to spend their days in it. If there is some ritual like work involved all the more better.
I’ve seen these guys come in from other organizations where they’ve used JIRA and the first thing they do is push for its adoption and use. There could be plenty of other things to tackle and I’m not here to make the case JIRA is or isn’t a good tool, has value, or is more or less important, I’m just sharing my observations. When you’ve literally made it your job to be the JIRA master, you are in fact more concerned with the performance of the work than the actual work product itself. It’s like the difference between introverted and extroverted personality types. Some people come in and want to get their hands dirty with the product and code, while others want to setup JIRA and start tweaking workflows.
Another brilliant thing I noticed they did was to optimize the scrum display for large TVs. Many issue trackers and other tools simply don’t look good (not readable) or are not functional on a massive 70” screen. The purpose of this is clear: for standups and planning meetings where it is used in a group setting (usually by the JIRA advocate/master).
Another big thing is the daily e-mails. It’s a way to show your boss and co-workers you’re doing something without telling them directly. And it makes people feel good to see activity, regardless of what is actually being done, it’s often times more important that people are working together, as 90% of all work done in JIRA is irrelevant anyway.
People talk bad about JIRA and despite its flaws you’d do well to study its workings if you are at all interested in building a similar B2B or enterprise app that requires a certain manipulation of the end user.
175 comments
[ 3.6 ms ] story [ 222 ms ] threadJira is a painful to use, especially compared to trello. They own trello now, so I hope they don't mess it up.
Its put in with reluctance rather than enthusiasm.
And to be honest, it's a process tool. Dealing with processes is boring.
Jira is better than bugzilla and trac. And much better than some tools, constructed from manure, from big IT companies and sold for very high price tags.
It's sad to me that they lost momentum. I think they got stuck trying to overcome tech debt and bug fixes and feature requests started to pile up.
From time to time I keep an eye on CommonMark implementations and fantasize about writing an MVP to replicate parts of Trac by composing existing tools. Unfortunately there are like 5 other things I'd rather do with my free time.
IMHO If you are a small startup and can be self disciplined, you don't need Jira. It is more for enterprise setup where accountability/responsibility has to be generally enforced.
I think this is some kind of natural law: any sufficiently old enterprise system tends towards becoming an ad-hoc, bug-ridden, poorly specified workflow engine.
Those reports are not generally being used to make sensible decisions, but they make management feel more in the know and in control and thats what really drives sales.
Jenkins comes to mind, Jira of course, and just about any other Java project's website still looks like it is from the 90s.
Also, all the big internet companies use Java, basically. You're using Google, Amazon, Twitter, Netflix, etc. products and you're using Java. Do you also hate those? :)
Furthermore, Java is mostly server side at this point so I'm not sure your UI complaint is really valid...
If you're using JIRA for stuff that Trello works for, then sure.
What JIRA does and does exceptionally well: grows with your organisation. You can start using JIRA for a simple ticketing system with 3 devs, then continue using it through 100x growth and still use it with multiple product teams, multiple development teams, overlapping projects, CI, code review, wikis, reporting tools, and so on.
If you think that all these tools and sophistication is bullshit, then that's a different conversation -- but a non-negligible number of smart people think that these integrations worth a lot.
JIRA is like Excel or Word -- 80% of people use only 20% of the functionality (or less), but it's a different 20% for all of them. And it's really-really painful to realize that Trello/GH Issues/etc. works great with a slick UI, except that it can't do that single stuff you'd really need because of your special situation.
If you can point me towards someplace visible that is using these tools well, I'm more than happy to be wrong. Every time I've seen them used, they're more like rorschach number generators for management, so I have naturally assumed that my experiences are the normal. That is, of course, a fallacy, so if you can point me to such a paragon of use, I'll be more than happy to check it out.
The strength of JIRA is that if your company suddenly needs a different development flow (whatever it is -- new tooling, new workflow, more teams, awkward regulatory requirements etc.) then you can stay with JIRA because whatever you want to do will be possible with JIRA.
(Uh, I sound like an Atlassian shill, even though I dislike the lagginess of their UI and also how they handle Bitbucket. :) )
This actually seems to me to be the biggest problem with JIRA... JIRA allows for the creation of arcane processes that very easily become burdensome because JIRA is very loose in its opinions. And, on top of that, the management of that process also often becomes a burden for the same reason...
And you're also stuck carrying around all the features you don't use...
Works as a general rule, too.
But I think this does get to the core issue with JIRA. Whether you "like" JIRA or not is more a reflection of your organization than it is a reflection of JIRA as a tool.
The agency I work at uses these tools together with ovur clients, as well as internally on different levels.
We have an internal project were we are just using tasks, subtasks with 3 states in a team of 9 in three to four locations. And we have a client, being served with about 100 people in different teams working on multiple projects, spanning multiple locations. Here we use the same tool. In one case with just a basic setup. One a 'little bit' more elaborate and customized...
And, of course, it's configurable, so any local installation of Jira can be tweaked in such a way that it's a pain in the ass...or not.
I've worked places where there was a high amount of incoming work, and no tracking, and it wasn't healthy. Lots of "squeakiest wheel", "who is working on this?" and other issues.
I am not sure who the 'management' would be in their case.
Just throwing something out there... But I wonder what the spread of these "smart" people is across "development" and "management"? The parent comment seems related to this...
> JIRA is like Excel or Word -- 80% of people use only 20% of the functionality (or less), but it's a different 20% for all of them. And it's really-really painful to realize that Trello/GH Issues/etc. works great with a slick UI, except that it can't do that single stuff you'd really need because of your special situation.
Also, just throwing something else out there... But I wonder, at what point, do we stop building tools that can work for 99% of the use cases and start actually having opinions on which specific use cases are "good" or should be encouraged? Because, like some of the other comments have said, a lot of those workflows that "only use 20% of the functionality" aren't exactly appealing.
The "tool" doesn't need to be overly "opinionated" just like a programming language, I want a tool to be flexible. It's my responsibility as the architect to constrain the tool/language for my environment.
Now, if there was a way to grow its user interface along with the organization's growth, it would be fantastic.
I feel like, as an industry, we should be moving beyond that at some point.
I've seen one dev excited - the one who tested other tools and picked Jira because it checked off on all the "features" needed. It really did handle the arcane and complicated workflow we had. But besides that few liked it, though it was a mix of hating the slow and unresponsive UI and hating the arcane process.
Instead of adopting a sound process, customers will take an overly complicated business process and make the tool conform to this process. And please note that in this cases how you manage your code workflow is, in fact, the business process.
Any tool will struggle - often it's the process that's cumbersome and not the tools.
For me, I'd love to have a flexible-enough tool for small to medium sized orgs that encourages a modern lightweight process and discourages ad-hoc process sillyness. Sometimes having a tool gently encourage better practices among all participants is a useful thing.
Can you expand on that? I've never seen a manager use it well. They use it to generate numbers for their reports for the people they report to, and it doesn't tend to matter what those numbers or reports actually represent. For example, it's very easy for process to make velocity numbers complete hogwash.
Basically, as far as I can tell, it's great and being able to tell you what you want to hear, and not very good at providing usable insights that increases productivity, but people don't notice because they're hearing what they want to hear.
For my money, the #1 benefit to scrum is improved visibility to stakeholders and any productivity gains to the dev are the result of them being able to work on things in the correct priority order due mainly to benefit #1.
One thing I definitely don't have is any managers living in it. It has all kinds of (useless, IMHO) reports it can spit out, but we don't spit them out, other one for time tracking some particularly-tagged issues (for the SR&ED tax credit program).
What is really awesome though is looking back through issues (and in general, JQL). For example, finding any re-opened bugs:
or building release notes (and excluding bugs that were found internally only): We generally just look at these in the UI (though I suppose you could consider this a 'report' of sorts).This is very anecdotal. To see JIRA used well, you need both management which is willing to invest the time and effort necessary to learn the ins and outs of configuring JIRA, as well as competent and flexible stewardship by the admin team to enable desired configuration in a way which fits in with the rest of the instance and doesn't pollute it. If you pay attention to recent JIRA releases, Atlassian is trying to enable management to make the changes it wants to make without resulting in global pollution, but either way, you still need management to personally buy in.
I've seen everything from managers who refuse to customize workflows beyond "todo-in progress-done" to managers who use post-it notes on the wall for their "real" agile board, and then copy the changes by hand into JIRA issues to communicate status up the ladder. If your company's management isn't buying in, your company needs to either replace the managers or replace the tool, instead of trying to fit round pegs into square holes.
Other tools, fogbugz, trello, etc are very good at what they do.
Invariably though when you get enough projects that are complex enough (not always big), JIRA has been the only thing that could take a bite out of managing the details like few others.
JIRA also can be greatly simplified to use but most users don't do this. The JIRA core offering is what I recommend to folks. JIRA is heavier for dealing with heavier projects.
On the flip side. Having a search engine of every issue and decision, be it design, system, implementation, roll out ticket for every project in a company is second to none.
I recently assisted a client in their systems design and growth from from 0 to 50m revenue in 4 years. It feels strange and wondeful to have every decision made in one searchable place, on one time line for every major piece of software or system implemented for them.
Most start from scratch projects can be nicely managed in Trello et al.
Generic search alone isn't the feature, or the benefit. None of those options listed have a deep enough search. GitLab and GitHub aren't a project manager - projects that are manageable in Git* likely aren't complex, or enterprise grade.
I have tried nearly every product in this arena as well over 20 yrs of dev in different types and sizes of projects. JIRA begrudgingly is my neccesary evil. I hear nice things about Pivotal Tracker as well, just didn't reach my sphere of folks when I was looking.
I can see the appeal of that. That is a killer feature for me. My team currently runs what I find to be a pretty lean and clean workflow using Trello, Github (for source control and issues), and Wikimedia for documentation. (Oh, and can't forget Outlook for release scheduling.) Having all of that in one place would make life easier.
On the other hand, not having a monolithic service handling everything has forced us to pay attention to our workflows and practices and keep them sharp.
But the team is small. If we grew or had to manage more projects across multiple teams, this would be really valuable.
I used FogBugz for almost a decade until the most complex projects I was working on dragged me into JIRA. I miss FogBugz' email first interface.
My Current stack is JIRA/Confluence on demand, the integration in the WIKI is simply too good to overlook. For product roadmapping I use Aha.io integrated into JIRA.. it's so far a more capable product than JIRA Portfolio, JIRA portfolio doesn't go high level enough. Harvest in the mix for easy time tracking.
The investment of time in integrating projects between Aha and JIRA so far has been a big payoff. We can literally start noodling with ideas high level, and as soon as those ideas cross the line into an epic, we have the sprint ready to go and automatically created in JIRA.
While it wasn't as smooth, the incredible detail we can manage things that need it, while leaving other simple items to hop through the steps that aren't needed was invaluable.
* The idea of the "Atlassian Ecosystem", in that buying more of their services seems to work better.
* On-premise for most of their tools
* Pricing. For example, Bitbucket Server - $26,400 for 500-1000 users /year [1]. GitHub Enterprise - $2,500 per 10 users / year [2]. Self-hosted GitLab - $39 or $199 per user / year (Starter compared to Enterprise Edition Premium package) [3]. If at a 1000 users, that is $26,400 compared to $250,000 or $39,000/$200,000.
* "Other big companies use them"
* "Reporting and metrics"
* "There is a plugin for that"
But, I and most of the other developers I have worked with hate every single Atlassian product we use. JIRA eventually turns into a micromanagement tool with all of the customization people think they want. People seem to think that because it is customizable, it will solve their problems. It always seems to take up more time and resources to try and bend their tools to do anything useful than it is to just say, "well, I guess we don't really need that".
[1]: https://www.atlassian.com/licensing/bitbucket-server
[2]: https://enterprise.github.com/features#pricing
[3]: https://about.gitlab.com/products/
https://bitbucket.org/product/pricing?tab=host-in-the-cloud https://github.com/pricing
Personally, I don't mind JIRA and the Atlassian toolset as they are so much better than what we used to use in the old days.
Processes (agile) and UIs (kanban) have been much more standardized in software project management and only now does it seem like some companies are coming up to give you that 90% out of the book with 10% the overhead/ management. Pivotal Tracker came close.. Clubhouse.io is the one I've seen doing it best.
They have quite different DNA. Tracker grew out of Pivotal Labs and it is mostly molded to how Labs and R&D teams do their daily and weekly work. To me it seemed constricted and limited until I came to work at Pivotal; now it makes sense.
Disclosure: I'm an Atlassian employee, but I had these opinions before I started.
Have never been able to use trello effectively with any clients. It's simply too open-ended on its own. "Issue trackers" (like Jira) have some semblance of workflow predefined, and act as a decent guide for people who are not "project managers" to still bring some degree of order/structure, with the benefit that that structure was actually defined by someone else who thought about data/structure/flow/etc.
Other examples include filtering and search. Google has raised the bar so high in both gmail and core search for how a query should work. Jira says fuck you here is JQL, and it isn't at all obvious why.
We are a large organization, and had an end of year crunch so naturally when you need to pinch the absolute most productivity out of your workers, typically process is the first thing that goes.
We just had our most productive 2 week sprint in over a year, by a mile. Instead of Jira, we busted out the dusty whiteboard, and used this amazing technology called an expo marker to write down what we were working on and who was working on what. It had amazing visibility too -- our manager could stop by at any time and see with his own eyes what we were working on -- all without having to log in! The best part? We got to ditch the meeting to plan the planning, the planning to plan the week, and the retro to go over the week to start of the next week's meeting to plan the planning. We got back like two entire days, and we didn't have any 9:00 AM context switches when most of us were in the zone already having to give a benign update that could have just been communicated via slack!
Some of this is sarcasm and I do understand why managers and leaders reach for Jira, but seriously: Why did we stop using the whiteboard. If you need visibility into this crap, hire someone to do that. You have analysts for your business, why not have an analyst for your tech? It doesn't make us more productive.
Because you can't do the following things without doing something other than "the whiteboard":
1) You can't share it
2) You can't back it up
3) You can't search it
And that's just for starters.
Shall I go on?
> 2) You can't back it up
The number of photos of whiteboards I've taken over the years beg to differ. Point 3 is certainly valid. Whiteboards definitely don't work for remote teams.
Because whiteboards aren't visible outside the rooms they're in, and they don't save histories of what was written on them in the past. If your org is scaling beyond a single geographical location, then you need some kind of system to communicate status to stakeholders elsewhere. Email and Slack are nowhere good enough for that; a ticketing system is absolutely vital.
I don't believe this. There were plenty of competing Open Source tools out with the same problems. I hated every single one of them and so did other developers I know. Perhaps developers preferred Jira because the management could be told they'd have to pay a qualified contractor for customization instead of torturing the developers with that kind of work?
I've only had luck with management (analysis and planning) of ticketing systems when we treat this observation as law. Either you measure what you have the data to measure, or you convince the developers that maintaining some part of the data is useful to them on a daily basis. The third leg of that stool is realizing that graphs and trends are for asking better questions, not for making decisions.
Everything else comes down to a weak appeal to ethics. The problem is that a lot of devs either have or think they have a richer sense of ethics (not necessarily better, but more considered) than the people who want the data. So these appeals come across as tone deaf.
This was used for > 10 years (for a few 10000 tickets) AFAIR until it got replaced by Jira. It worked well and was accepted (or so it seemed) because it didn't really interfere with the typical way of doing things till then (e-mails) and offered minimalistic features on top.
Like the sibling comment, my own encounters with it have made me think more of the deli counter...
I don't doubt that this is the case. I worry that this begins to approach a "cargo cult" manner of thinking about development.
I can't help but wonder if this trend favours younger developers, who may not remember the days before Scrum became such a widely-practiced management style.
>Like the sibling comment, my own encounters with it have made me think more of the deli counter...
No doubt. Instead of being judged by lines of code, the deli worker now has to concern themselves with things like "velocity" (in which case, Jira has become a prime tool).
Vendors come in and bullshit your bosses and the purchasing authority about how awesome their tools are and all the things it can do.
By the time the developers catch wind of it the check has already cleared, and they -have- to use this tool because someone with firing authority paid for it and you're not going to get away with embarrassing them by calling them on their bullshit (young me tried, young me failed).
I'm not aware of any development team that consciously picked Atlassian. Atlassian gets picked for them. Their success is in selling to the management chain, not in being a good product. Because they aren't (but then neither are many of their commercial competitors).
Disclaimer: ex-Atlassian
So what is this site anyways? There's no About page, no contact, no ownership information, no author, nothing. Looks like an advertisement to me.
Somehow, they managed to accumulate the negatives of a flexible product (resulting in poor/incoherent UX) and the negatives of rigid assumptions regarding workflows (try modelling staggered deployments in different datacenters/environments spanning multiple sprints... good luck!).
Going forward, I expect Atlassian to cater to rigid organizations and neglect those who design their own processes (whether lightweight ad-hoc or complex custom ones that don't fit what Atlassian Sales can understand).
There is an enormous amount of hate directed at JIRA that is a side effect of customizations created by admins. People abuse the customizability and their own internal users suffer the consequences.
Atlassian's own public issue tracker is using a near-default issue display screen. Nothing is "below the fold" for me on this issue and on a small monitor: https://jira.atlassian.com/projects/CORE/issues/CORE-1055
> Last commented: 1 year, 13 weeks ago
> There are no comments yet on this issue.
Maybe a large part of the hate is genuinely about the default configuration and UX.
It appears the issue in question was commented on 1 year, 13 weeks ago. But the comment isn't visible to the public, thus the "no comments yet" message.
I showed the CTO and CEO ZenHub and we're off to the races.
It’s probably inevitable but a policy requiring strong justification for and regular review of any “aftermarket” changes might slow down or reverse the descent. The closer it is to vanilla the easier it is for (almost) everyone. Managers and workflow czars (nice one btw) of course would be inconvenienced but they should be comfortable making really strong justifications for making the lives of developers harder just to make their reporting smoother.
I attended a talk by a Netflix employee where they talked about a sort of organizational immune system to aggressively prune bureaucracy and policy by forcing it’s existence to be regularly justified. It helped me connect the dots and realize that allowing heavy customization was as much a poison as it was a boon.
One axis is number of people actively using the tracker for a single project — I personally think that threshold is around 50 people^1. Another is workflow complexity — very few tools are as capable of mapping business processes to software as JIRA^2.
1. Careful, there's another threshold at which JIRA becomes painfully slow. At that point you either move to something that's less adequate in nearly-every way but scales or you start splitting JIRA instances by department or project.
2. Careful here as well! Poorly created JIRA workflows are probably _the_ #1 reason people hate using it. Users learn a highly customized JIRA workflow and think it's absolutely bonkers that Atlassian did this to them, when really it's their company's customizations that are causing the pain.
If you look at the most recent changes to Jira, like the Agility boards announced at Summit, it’s about starting from as much flexibility as Trello and expanding to as much power as standard Jira (if you need/want it).
Disclaimer: ex-PM on Agility boards, no longer at Atlassian, opinions are my own.
Spartez has obviously been a great partnership but "large bits of their core offering" is inaccurate. That's not to deminish the efforts of the people involved. It's just materially untrue for most values of "large" and "core".
No, it can't. Atlassian's tooling is used by large teams. It doesn't make sense in a small team environment. In a large team of say a dozen people, can you imagine managing accounts/permission/access to a dozen services? That's over 144 accounts, plus billing, plus all the other stuff needed to make everything play together. Nobody wants that headache.
That's just the tip of the iceberg too. Atlassian already plays well with Github and other services. So you can have your cake and eat it too.
This is really the benefit of Atlassians wide product funnel at the top. JIRA might be the Worst Thing Ever, but it can be configured to needs and integrates well with most-everything. In a lot of Enterprise scenarios the most win/win solution can be using JIRA as your default and master data while teams and projects are using integrated too stacks.
That way your suits can have standard tooling across the board, your sensitive issues are all registered in an on-prem installation, and your dev teams are free to find The Right Thing for them.
Atlassian/JIRA is a platform as much as a product. With its integration story and plugin market you don't need to swallow it whole parcel, and it's easily an industry leader in that regard.
You just need the glue.
GitLab Omnibus has Mattermost integration, but you could also look at Rocket.Chat (and in all honesty Discord is a kickass free alternative to Slack).
Atlassian is free to use and invent what they need to provide a given feature.
Granted, it can take years, but compared to a collection of Add ons, "beats" a mix-and-match tool set.
I agree that there are better services if you don't mind running on other people's infra. Behind the firewall Jenkins I'm not sure about, I haven't tried it in ages.
JIRA's most powerful feature is that it affords for mapping businesses processes onto software. This is incredibly compelling to enterprise customers. Software that enforces workflows, procedures and requirements can be an incredible lever and JIRA's price point makes build vs buy decisions an absolute no-brainer.
The down side for the true end-users, those who actually use the software day-to-day, is that most business processes are awful.
If your experience is the hellish existence that I see strolled about on threads where JIRA comes up, I can say with near absolute confidence that it's because of one of three things:
* Your admin(s) set it up once and hasn't bothered to iterate on those workflows. * The business mapped their autonomy stripping processes onto JIRA intentionally. I'd guess that most of your work experience is similar. Process stifled nonsense. * You're on an instance that is serving too many people with too few resources. Shard your instances folks, the money for extra licenses is wildly cheaper than the human time you're wasting waiting for stuff to load.
I think we can just admit to ourselves that JIRA is bad. It’s ok to say it.
I interviewed with Mike and Scott when there didn't seem to be many other people involved. A few days later the company I worked for started the process of getting acquired.
I tossed up what I thought my share options might be worth against two guys who seemed to be just out of uni with a bug tracker.
I called them back and said I'd stay where I was. My options were worth nothing. Joke was on me big time!
Later on lots of my dev team ended up working for Atlassian and I thought it might be time to check it out again. I went for an interview and was told I wasn't smart enough, despite the fact I'd already mentored a bunch of their devs.
At least they gave me an interview. Most places don't 'cause I don't have the book learning to get past HR.
in other words, they found a market need others ignored, and they served it.
I work at another ASIC company (Storage Industry) and we use JIRA as main issue tracker; JIRA feels very tailored for ASIC, at least the version at our company
Source: https://en.wikipedia.org/wiki/Atlassian
I have a theory that much of the success of web-based companies isn't due to the internet's reach itself, but because they can actually harness programming to business. Make something happen; check for something; modify everything. Of course, there's always problems with programming but it's so much easier than doing it any other way.
But traditional businesses cannot reap these benefits, because they cannot make IT central. They can't be IT first. And they lack the talent and experience to handle all the problems of programming. Therefore, it is the new web-based companies that know what they are doing (with programming) that win this.
The quote above is a great example: it's hard to integrate acquired businesses, they usually just become a messy "conglomerate". What if you could actually integrate other products and services into your products and services? With programming, it is possible, whereas it wasn't really before.
There are still problems - and other commemts highlight how the UI has suffered. Indeed, enlarging a codebase inevitably has much in common with a messy "conglomerate". But it's so much easier than doing it in any other way than with programs (i.e. traditional businesses).
(Atlassian's products also help other businesses run on programs, but that's not my focus here).
It's somewhat scary the breadth that AWS has in their ecosystem now; however, Bitbucket is wrought with issues like:
- no large file collapsing, i.e. lock files
- random downtimes ( I wonder if they actually meet their SLA )
- feature requests on boards where Atlassian members ask why x is needed, followed by a slew of +1's, to only see someone ask 3 years later, "where is this at?"
I'm a jaded Atlassian user who believes they buy competition and then stagnant the product's evolution.
Positioning it more like:
- It will save us X amount of time on average
- Give us better security through IAM
- Reduces fragmentation across org software
sells a lot better to people with credit cards than, "I like it more"
What product do you think Atlassian has bought to stifle it's evolution? Bitbucket specifically was a product with 50k users and Atlassian has grown it to Millions. Buying a competitor just to let the product stagnate and die makes rarely sense in business.
Hipchat could have easily taken the space that Slack exists in. Lack of product vision and resources dedicated to the project ultimately led a non-existent competitor to own the entire market.
By the way did you see Trello is now part of Bitbucket as a default?
What exactly was HipChat competing with in the Atlassian portfolio when it was acquired? Nothing. HipChat was three people when it was acquired. It was over 100 not long after. That space grew so fast that you could argue maybe Atlassian should have put 200 on it. Regardless, it got the biggest investment of any group chat tool in the game at that time. Slack did an amazing job in the viral growth front. Credit to them. Atlassian is beefing up HipChat for enterprise/BTF and launched Stride for everyone with an email address and a need for something more focused than slack.
JIRA has an uncanny way of attracting to it a very specific (and valuable) person inside organizations.
I mean the person who is obsessed with the creation and quantification of knowledge worker processes that are subtly complex. This complexity naturally gives plenty of fodder and massive surface area for engagement and features —- one can spend hours tweaking JIRA workflows, running reports, and playing with the query builder. And we all know that once a user is engaged past a few days you’ve got them, almost like a kind of pair bonding. They have bonded with your software, and they’ll be forced to spend their days in it. If there is some ritual like work involved all the more better.
I’ve seen these guys come in from other organizations where they’ve used JIRA and the first thing they do is push for its adoption and use. There could be plenty of other things to tackle and I’m not here to make the case JIRA is or isn’t a good tool, has value, or is more or less important, I’m just sharing my observations. When you’ve literally made it your job to be the JIRA master, you are in fact more concerned with the performance of the work than the actual work product itself. It’s like the difference between introverted and extroverted personality types. Some people come in and want to get their hands dirty with the product and code, while others want to setup JIRA and start tweaking workflows.
Another brilliant thing I noticed they did was to optimize the scrum display for large TVs. Many issue trackers and other tools simply don’t look good (not readable) or are not functional on a massive 70” screen. The purpose of this is clear: for standups and planning meetings where it is used in a group setting (usually by the JIRA advocate/master).
Another big thing is the daily e-mails. It’s a way to show your boss and co-workers you’re doing something without telling them directly. And it makes people feel good to see activity, regardless of what is actually being done, it’s often times more important that people are working together, as 90% of all work done in JIRA is irrelevant anyway.
People talk bad about JIRA and despite its flaws you’d do well to study its workings if you are at all interested in building a similar B2B or enterprise app that requires a certain manipulation of the end user.