7 reasons why use of Jira can be frustrating, part 1

[#1]

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.

I’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, I'd say 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.

Jira Cloud users also can make great use of the Roadmaps feature which is part of the new experience introduced in 2018 by Atlassian

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 we and our 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 — we can do waterfall, Agile, plan your wedding, or track our favorite wine and beer inventory with it.

With the new next-gen projects on Cloud, we can turn off all the agile stuff in two clicks if we don’t need it or just not bother with it from the very beginning

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 a number 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 the 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.

This is the first part of the article. Read the second part to learn 4 more reasons why Jira is criticized and possible ways to solve them.

[Lawrence]

How to include JIRA query for reach of member with a total count of tickets as a link to display all the tickets that a person opened in a confluence page?

[Dzmitry Hryb _Deviniti_]

Hi @Lawrence

If I get you right, you need the Jira Issue/Filter macros set up to display the issue count as a link to the Issue Navigator. Like this: