7 reasons why use of Jira can be frustrating
Love and hate are often two sides of the same coin, especially when it comes to someone or something we interact with every day. We spend at least one third of our lives at work, which inevitably makes us feel strong emotions. As we tend to work in dislocated teams or a culture that encourages to use technology for communication, we spend a good chunk of our time in some kind of a project tracking tool. Over 50,000 businesses around the globe use Atlassian Jira for this purpose and require at least its basic knowledge from their new hires. Because of that, this software has eventually become an unquestionable IT industry standard, and is now actively expanding to non-technical teams as well as personal use. But the more people get hands-on with the tool, the more diverse opinions appear on the web about both its general usability and specific features. Let’s go through seven most common reasons why use of Jira can be frustrating, try to understand where this frustration comes from, and think of possible ways to turn it around into an everlasting love relationship.
1. Jira is not designed for project management
One of the biggest Jira haters out there is Jon Evans — “a novelist, journalist, and software engineer”, as his bio goes on TechCrunch where he writes a weekly column. His articles Death to Jira and Jira is an antipattern present the software as incomplete and “lacking vision of the big picture”, with the arguments taking root in the tool’s origin as a bug tracker and thus featuring tickets as basic building blocks. Evans claims that the process of breaking down work into small tasks and assigning them to the team members makes their focus shift too much to the ‘micro’ side and forget about the ‘macro’ one. Without the context, he writes, everyone cares only about their own issues, so the teamwork becomes just running the tickets through the board, and the resulting code is far from optimal.
We’ve also heard voices elsewhere saying that the equation of Jira tickets to the work actually done leads to “no Jira — no work” approach, which is a common excuse for some folks to refuse helping their teammates. Another claimed drawback of management through Jira is reports consisting mostly of velocity and ticket burndown charts, which often don’t show the actual amount of value brought to the customer as an outcome and even may make the case for the C-suite to compare different teams.
Now, while these allegations all come from practice, one could argue they have very little to do with the tool, and much more with its misuse or the organizational culture itself. Sure, Jira on its own doesn’t have the capabilities for proper project management, but there’s clearly a reason why Atlassian developed Confluence. The second tool allows to create product sheets, track requirements, and link them to Jira issues, as well as document the overall business strategy for a given project. Moreover, there are over 500 apps now on the Atlassian Marketplace in the Project management category for Jira Software so even if one doesn’t want to buy Confluence, one can easily find a suitable alternative.
Another problem is having the right management software in place, but lack of transparency in terms of sharing the information with the development teams. The devs need it to understand the global assumptions behind the project, start tinkering at the atom level, and integrate tiny bits of code into a working system. Instead, people in charge of managing the project decide to keep the requirements top secret and let the devs blame the tool instead of the process. The situation with reporting is kind of similar: if we accept the fact that products on the market come from their target audiences’ needs, we should take a closer look at the way we measure teams’ effectiveness first, and check if it encourages toxic behavior. Trash KPIs and useless reports based on them are the problem, not the tools supporting such reports. Again, there are 200 additional reporting apps for Jira available on the Atlassian Marketplace which cover everything from advanced time tracking through Gantt charts to solutions allowing to create custom reports of any kind. They all can be viewed on a single screen, if we take some time to configure a compelling Jira dashboard.
So, as commented by Jordan Janis on one of Evans’ articles, ‘allowing a tool to define our process is the real antipattern’. We should actually do the opposite and make sure we’re already doing the work right before engaging with software.
Defining a process that works for the company first, then picking out the right set of tools to support this process and enabling access to high-level project data for all engaged parties are the key action points leading to a successful software development project.
2. Jira doesn’t fit into Agile software development
The first principle of the Agile Manifesto is probably the most radically understood one. From one side, agile purists claim on its basis that ‘Jira is a step back in terms of Agile, as it disconnects people and makes things overcomplicated’. From the other one, there are managers trying to implement tools without setting up a workflow first, being afraid that it would turn out too rigid and not so agile anymore. When the second principle comes into play, one complains that dates are the sprint target rather than story points and claim that we should be more focused on the code. The others equalize Jira with the whole Agile methodology and criticize it for the specific terminology it operates on, let alone the issue concept, or for the backlog often being a graveyard of user stories.
The bad news is that we should turn back once again and take a look at the way we work, forgetting for a moment about the technology we use to help ourselves. An agile process basically starts with a whiteboard and a pack of post-its, so any software tool can come and help only once the team establishes the workflow, knows it well and has it tested. Moreover, not every project needs an agile process just because it’s been another cool buzzword for the last couple of years, or someone went to a conference and heard that it’s the most progressive way to make software. If we have a team of 1,500 people creating a big and clunky system for accounting, we may not necessarily need to release once a week and reorganize the whole process, as it may turn out too costly and time-consuming for the project. It’s only a matter of how you and your team agree on to keep things running, what to be the sprint target, and what to do together to keep the backlog clean — that’s how the first Manifesto principle works in theory.
For sure, Atlassian promotes Agile project management by both including Scrum and Kanban boards into Jira projects and supporting them with the Agile Coach guides, but neither are they the creators of this approach, nor did they create Jira specifically for it. The first version of the software was released in 2002, when most companies were still doing things “the old way”. Besides that, Jira is just a tool — you can do waterfall, Agile, plan your wedding, or track your favourite wine and beer inventory with it.
3. Jira is too complex to be used effectively
Projects. Boards and dashboards. Issue types and screens. System and custom fields. Priority and permission schemes. User groups and project roles. Workflow statuses and transitions.
Such amount of things to keep in mind when configuring a ticketing system can easily confuse an inexperienced admin. It goes without saying that a big instance can be a real clutter to manage, and everything looks a bit different on Server and Cloud. But apparently, truly technical people love to dig into things deeply and delve through complicated configurations. This is no surprise, as their primary means of communicating with computers is the command line terminal. Unfortunately for them, Jira is coming through the process of simplifying its interface and making things more intuitive for those who don’t have such habits and prefer the drag-and-drop way of using software.
In the article about the new Jira Cloud release, TechCrunch quoted Atlassian’s Head of Growth for Software Teams Sean Regan, who said: ‘…when Jira was first built, it was built with a single team in mind. Today, there’s a mix of teams from different departments that use it.’ Old school software cats and the almighty IT crowd may not like it, but 43% of currently open jobs at tech companies are non-technical roles, so naturally the new Jira’s goal is to be the tool for whole organizations. The project planning tool tries to encompass use cases for each role from business to HR, and Scrum teams consisting of people with different skillsets are also pretty common now. So there’s been an urge for a twist to Jira’s UI which would help those new to the tool use it seamlessly and not necessarily become power users to perform simple tasks. Such a twist was successfully found in Trello, which has been the most strategic Atlassian’s acquisition for the last years, as Jira is borrowing much inspiration from its younger sister.
A unified system for a company counting up to 10,000 or more employees, where every team needs to do something in a different way, just can’t be simple for everyone. Most often it’s the admins who suffer and have to go for a compromise — while one simply needs to know where the Create button is and what to type into the fields to create an issue (even Jessica Alba can do it, come on!), there’s a whole lot more knowledge and effort required to set up a project or a whole instance. Moreover, having all the configuration power in a single pair of hands isn’t the best choice when a team needs to implement changes to their Jira project. In big corporations, they may not even know who to ask about it! This situation doesn’t also feel very pleasant from the other side, because it doesn’t bring any benefits apart from pleasing someone’s ego for being irreplaceable. The drawbacks are much more severe, including significant budget loss for larger teams and lack of time for the admins to do the work that really matters. However, enabling agility projects which are completely independent for every team can take quite a lot of work off their shoulders. The only thing to do then is just some training to prevent harming the overall performance.
4. Jira is lacking features
The other consequence of the one-size-fits-all approach is there are no native features in Jira for some use cases, so it often requires adding a significant module to the system. Other features demand for extending their functionalities or making them more adjustable, and some more may involve usability improvements to fit into the particular context. Besides having over 3000 employees at 6 locations around the globe, Atlassian simply doesn’t have the capacity to implement every single feature request from their clients, given the amount of products they create and maintain. So naturally, other companies picked up the baton and started developing extensions for their clients’ implementations, some of which then were commercialized as apps. That’s why Jira is known as a highly flexible and customizable solution, but now we don’t always have to write custom scripts and features as there are over 4000 apps available on the Atlassian Marketplace.
Some might argue that each app costs additional money to the already paid license, and many of them should be included into the out-of-the-box version of the software. It may be true, but when we step into the Ecosystem, we can quickly find out that it’s full of amazing helpful people whose input gives back at least as much value as we invest into the apps we use on our instances. For those concerned that third-party apps might break both stability and security of the system, the experienced Community members share the best practices on evaluating and implementing them properly.
5. Jira’s UX/UI are clumsy and inconsistent
Yes, the current Jira configuration experience is not very helpful. Tons of elements that the tool consists of and the multitude of parameters for each one result in literally flooding us with settings, which are pretty hard to get organized. This is something that hasn’t been touched directly by the latest updates, but a lot has changed for the end user experience instead.
From the beginning, Jira has been aimed excusively at a technical audience, so the IT crowd can naturally feel odd when trying to type a JQL query into the search bar of the new Jira Cloud and getting no result. People got used to the previous version and want to do their job without having to learn their tools from scratch. Once, we helped one guy on Twitter to find Create a sub-task button on the new issue view, which was right in front of his nose. Then he accepted that it was actually a faster way than the old one, but we still can understand why people get frustrated with showing up at work one day and seeing a completely new screen. The feeling is even stronger due to Cloud instances upgrading themselves automatically.
Another claim that we came across is that Jira’s UI is inconsistent if we compare Server and Cloud offerings. Let’s make it clear: it’s incredibly difficult to create identical user experience across 15 products on 3 different hosting options. Sometimes, there are technical differences that successfully prevent the creators from making it identical, and another reason is the diversity of customers’ groups and their particular needs for each product and hosting. As it came out from the surveys Atlassian conducted, ‘Server is most customizable, Data Center is about scalability and minimum downtime, and Cloud are basically smaller teams/businesses that […] want to have a simpler setup’. The admin part is far more extensive on Server as well — not because of Jira itself, but just because of the necessity of having a dedicated admin and maintaining own infrastructure for the software. However, Atlassian has already made the first steps to make Server and Cloud interfaces closer to each other.
6. Jira is slow as !&%$
During the Atlassian Summit Europe 2018 keynote, Atlassian Head of Server Cameron Deatsch shared a story of one customer who had 124,000 issues in their backlog and had to wait for it to load for so long that they simply tied their coffee breaks to reloading the agile boards. At some point, the team behind the tool realized that scaling their customers’ businesses should be tied with ensuring high performance instead. That’s in brief how the Data Center offering hit the market in 2015, and after enriching it with specific features, the next step was to upgrade the whole Server platform and fix these annoying issues.
The most significant thing to do was to upgrade Lucene — the library used for indexing and searching in Jira, which was the main cause of time-consuming pageloads. Then, another insight was that no one ever needs the whole backlog at a time, so there’s no need to load more than first 90 and last 10 tickets at the pageload. Somewhat less important but still affecting performance were Java and jQuery upgrades. Among other improvements, Atlassian reports 60% faster boards, 87% faster backlogs and 71% faster reindexing after performance tests with the new Jira Software 8.0. Below is the result of loading a heavy backlog comparing to the previous 7.12 version.
However, Jira’s performance doesn’t depend only on its codebase. It also needs to be managed in a proper way to ensure things don’t go even worse. Sometimes, people don’t upgrade their instances for ages and then complain about lack of performance improvement. It can work out with Cloud, but it won’t with Server where we have to watch for the new releases and upgrade manually. At the Summit Europe 2018, we came across a guy from a big company who said they still had Jira 5.x, so we assume such things happen in organizations. Ultimately, people are frustrated by the amount of time spent in Jira daily, which we can optimize by reducing the amount of custom fields or introducing templates for frequently created issues.
If we keep our knowledge up to date, our instances will follow us quickly.
7. Atlassian is not as helpful as the customers expect
If it comes to gaining this knowledge, though, one could get overwhelmed pretty easily. As Atlassian have practically no sales reps, they’ve bet all-in on content covering both technical aspects of their software and broader topics around IT, teamwork, leadership and such. Given the amount of information one should process to get enough trust and understanding for a purchase decision, they’ve hit the bullseye with this marketing strategy, which is reflected by their stock performance. However, the problem of organising this much content came up over time — on the Atlassian Community, we can hear voices saying that the technical documentation for Atlassian products is ‘a willy-nilly free for all’, or that ‘it’s easier to do a Google search on the topic than trying to find something in Jira help’. Aside from the vast product docs, which sometimes are really difficult to follow, they offer us a thought leadership blog, six topical microsites, a separate portal for app developers, and plenty of live webinars and recorded videos. While all these are obviously targeted to different groups of people, and for sure there’s a lot of folks who absolutely love bookworming for the nitty-gritty, for many it isn’t the most pleasant activity at work — hence the frustration about it.
Then comes the matter of Atlassian’s own Jira. At the moment, it counts almost 20,000 bug reports and feature requests for Jira Software Server, and just about 2,000 less for Cloud. Provided that a big chunk of these have been in open status for a good couple of years, the customers feel like Atlassian seems to ignore their feedback. Even worse for them is “Sorry, we won’t fix/implement that any soon due to the current product priorities” response without a proper explanation what these priorities are and why so. However, the latest releases claim to feature the most voted improvements, and we’ve seen their Twitter support doing a great job with helping people out. Also, it seems Atlassian just delegated most of the help to the Ecosystem itself, so they can focus on gathering feedback and improving the actual products.
Lessons to learn
To sum it all up, we can see lots of ambiguity among people treating Atlassian products. What’s considered as flexible by one part, is rigid for the other. Some don’t feel like paying for additional features, others totally love the idea of customizing the solution. Business and non-technical folks want to keep everything simple and intuitive, while the angry nerds like sifting through the endless docs and coming up with workarounds. Basically, there are as many opinions as many heads, but both sides can learn a couple of constructive lessons from them.
Dear Atlassian, now that you cared for the business and end users so much, maybe it’s time to make it a bit easier for the folks responsible for keeping your thing going at their organizations. We understand that you’ve operated on a single code base for almost a decade, and improving such a complex system for each user segment takes much time, but there are already almost 3 milllion users on the Community who are mostly Jira or project admins, and this number is growing quickly.
Dear haters, please remember: there’s no tool which could substitute a solid working process and communication in the team, and if you already use Jira, try to learn it as much as you can to achieve better results. Common sense suggests that most often, your Jira experience is as good as your knowledge about it. So try researching the Marketplace in search for a solution, asking for help on the Community, participating in an Atlassian User Group, attending an Atlassian Ecosystem event, or reaching out to a local Solution Partner for a consultation or staff training.
This article was written by Dzmitry Hryb.
