What Atlassian won’t tell you about JIRA!

Today’s world runs on software, and companies rely on solutions to help manage the work. Tracking what needs to be done, when, who is working on what, etc. are the typical needs for software engineering management. This is where lots of companies choose Atlassian’s JIRA.

Atlassian continues with their great marketing push, claiming lots of innovations. If you believe the hype, they may even be on to something, however, they won’t talk about the biggest issue. The hidden costs of tools like Jira! We aren’t just talking about licensing costs or hidden fees of Atlassian. While many companies do express the frustration of having to pay for user licenses for Atlassian products that they do not use, this post is about a much greater role Atlassian JIRA’s plays in the software development tech stack and the large hidden costs associated with its implementation.

The Sunk Costs of Configurations

Whenever a new engineering team starts using JIRA, the team quickly faces a need to set it up to reflect the team’s development process. This obviously takes time and resources that are not accounted for when someone selects JIRA as the software development “go to” tool.

If your product or project involves many teams, each team will go through its own setup period of configurations, and probably adapt and change the configurations continuously throughout the development. Some companies have small dedicated teams of full time configuration experts that handle JIRA every day. Other companies want their developers to work on the products and not be distracted managing the tooling, so they hire outside experts to help. Either approach requires a significant investment, and the more complex dashboards, workflows and processes that are desired, the more investment managing them is needed.

Certainly, when development teams acquire essential tooling like databases, cloud environments, system monitoring there are always expectations of investing into experienced engineers and administrators to manage them. After all, these systems are responsible for keeping things running smoothly as the performance directly impacts the quality of the service and customer experience. However, is it worth investing hundreds of thousands dollars a year just to manage a project management system?

Most agree that perfecting the software development process and configuring tooling is by every definition — waste! Any time not dedicated towards the goals to drive business outcomes is a burden of time and effort — which is essentially a burden of money.

Inefficiencies in Individual Team’s Processes

Teams using JIRA invest a significant amount of time to conform it to its own “preferred” development process. This is not bad if it’s a single, small independent product team. But for larger, multi-team products and projects this quickly turns into a managing nightmare. 

Every team operating differently is a recipe for disaster. Spotify was the first to develop its own versatile team operational model with every team selecting to run itself independently and it quickly ran into the wall with scalability. Spotify quickly learned that it’s impossible to scale teams that operate differently. By definition, scalability requires a repeatable process – something that is common across the organization so it’s easy to collate the data, assess the progress, and implement changes to improve the development process overall. 

This is where companies generally fall into 2 categories. Some allow teams to customize what they want to do and how, and run into challenges with scalability and transparency. Others employ strict governance by senior leadership controlling the development process and become unable to change become subjected to heavy bureaucracy and unnecessary steps holding everyone back. These constrained teams are forced to operate in a restricted, cumbersome environment that stifles efficiency and creativity. Both of these options add to the hidden costs introducing the tax productivity. Often, the tax is so great that it takes weeks or even months to accomplish even the simplest tasks.

The Gaps in Product Management Capabilities

Modern software development is done via a discipline of Product Management. However, JIRA lacks all tooling necessary for products. The Roadmap is really just a set of Gantt Charts, which serve very little value.

Gantt charts were invented in 1915! They were created to represent repeatable, predictable, manufacturing steps. The fact that we apply them in modern ever changing reality is absurd. In Software, Gantt Charts are used as lagging indicators of progress, manually tweaked by the management and thus, they never represent the true state of the execution. They are subjective and used to justify the progress for higher levels of management often way too optimistically than the reality. After all, no manager wants to be seem as unable to manage delivery expectations.

The lack of Roadmap visibility is one of the reasons why you’d often find companies buy JIRA for software development and another solution like Monday, Wrike, Asana, or Clickup for Product Management. We also see customers buy Product Board, Aha, and other tooling to marry with JIRA because despite JIRA’s vast configurability, the right functionality for the Product is really lacking. This is more evident by the presence of the additional tooling for metrics — tools that pull data out of JIRA to give you nice metrics dashboards for displaying the data and trending of throughputs, cycle time, and others. Tools like JellyFish, LinearB, and many more are employed for this very need.

What project management learned from DevOps and Marketing is that the focus on metrics driven approach is indeed very important. One cannot fix what they cannot see. Hence comes a question. Shouldn’t the system like JIRA provide their customers a way to demonstrate those metrics out of the box? After all, having 300,000 customers should have given Atlassian a lot of opportunities to collect the feedback to figure out what to build for their users. Yet, this falls on deaf ears and this lack of capabilities again ends up costing JIRA customers more money!

Significant Inefficiencies by Lack of Visibility

JIRA started out as a ticketing system and while it was converted to help manage a software development process, it has a very significant gap in functionality — the one that limits the visibility of progress.

For starters, JIRA lacks the concept of Centralized Product Backlog. Each team in a multi-team project has their own workspace with their own individual Roadmap, Epics, and the Team Backlog ( again, in JIRA it’s a Gantt chart, not a true Roadmap ). This means that all teams working on the same Product or Project will only have visibility into their own work, not the work of the entire project. This has several significant drawbacks.

1. It’s impossible to see the top down view of how the work is distributed by multiple teams in order to find areas to help the team, or to plan the next direction.
2. It’s hard to recognize and track intra-team dependencies, which are the biggest impediments to getting things done. 

This puts a lot more strain on the product organization to be thorough managing each team’s direction separately. One of the most frequent team complaints is that the teams do not understand the goals, and because they are measured against individual goals, they often contradict the main product goals. Lots of teams struggle to understand how does one team’s work fits into the overall #1 Project Goal. The lack of visibility is very apparent. 

Senior leadership does not use JIRA, not just because it’s complex and hard to navigate, but also because it doesn’t give them the details to quickly assess the state of their projects out of the box. Instead, JIRA offers it via additional products like Jira Align and now Jira Focus – again costing more money. If these tools aren’t used, organizations compensate for this limitation by requesting every team manager to submit a monthly/quarterly progress report – a custom built powerpoint presentation that is totally unnecessary if the information was presented and clearly visible in JIRA. Another form of costly waste. 

Due to the lack of visibility and desire to automate things, companies with deeper budgets solve this problem investing into BI Tools to assess the progress. First, JIRA is updated with custom fields to track work belonging to which project or initiative. This becomes a required field for every work item that engineers are required to enter, adding yet another burden on development teams to set fields correctly. Then, at the end of each month, the data is exported from JIRA into a BI tool and crunched to provide a result – “Project X is 78%” complete. 

We know how silly it sounds, as “78% complete” is absolutely not an accurate measure of progress by any means. It looks good on a custom powerpoint presentation to the Senior Leadership, but nothing more. The trouble with this approach is that the costs of product or project development and the need for continued investment delays proper decision making, and quickly becomes expensive when wrong decisions are made, decisions are made too late, or not made at all. For example, “We can’t possibly complete all of the features by the desired timeline, we need to adjust the scope” is a very common problem. But if organizations aren’t able to recognize being late, they run into unpleasant “last minute” surprises.

Therefore, without a clear understanding of teams’ progress, companies just fall back to micromanagement to help run software development. This puts yet another strain on the organization and limits the teams from being able to perform at their best.

Eliminating micromanagement has shown to yield 25-50% increase in teams’ productivity! With JIRA, however, that is extremely difficult to do. The lack of visibility, leads to lack of trust, and lack of trust promotes the behavior of control. All leading to micromanagement that costs organization dearly in the long run.

The “JIRA” things that lead to inefficiencies

Everyone has experienced running teams and herding engineers like cats to have them update their status. Just one of the examples causing significant inefficiencies that end up costing money. Proper status helps optimize the handoff between different people on the team, helping close out work sooner. And we know that the biggest inefficiencies in software development is not writing code, but rather waiting in between code writing, passing work from one to another.

There are many others.

• Added backlog items added in the end of the backlog always missed and ignored
• Hidden work in between of work items because working with SubTasks is truly a pain
• Pre-assigning work to entire team
• Lack of clear prioritization of features and backlog item
• Unable to visualize completed work without complex search queries
• Useless reports with focus on vanity metrics that instrument poor management behaviors
• No dashboard for senior leadership to assess the progress of various initiatives
• Poor search functionality
• Outdated and cluttered User Experience 
• The need to know how to use JPQL queries for more advanced features
• and more…

Its not a coincidence that developers hate JIRA. If this is the first time you hear about it, just ask yourself how badly things need to be that someone actually went and created this site to voice honest JIRA reviews. Don’t believe folks posting on this site? Ask your team their true, honest sentiment!

One would imagine a company like Atlassian to address these, but JIRA largely remains the same over the years, with biggest changes just added on top, minor face lifts, but largely retaining the same outdated structure. Not a surprise, with so many customers, and everyone using the solution differently, changing the underlying architecture and design is practically impossible. In the meantime, users continue to work through the inefficiencies and wasting precious time and money.

Plugins and Integrations

JIRA is rich with integrations and back in the day, when it introduced the JIRA Marketplace — it was an exciting novelty. Today, JIRA has thousands of plugins and add-ons. But… There is a catch. Each one ( hopefully a useful and valuable one ) will cost you more money!

Want to track CapEx and OpEx for financial reporting? Tempo Timesheets — $$. Want to do export/import or integration with other systems, buy other plugins — $$. Would like to get unique reporting out of JIRA — here’s another tool or plugin — $$!

It’s not uncommon for companies to spend tens of thousands dollars a month for plugins that should have been a part of JIRA in the first place. Why doesn’t JIRA continue to build out the tooling? Well, they earn revenue share from the Marketplace. Practically a free flow of money from tooling that someone else develops and maintains! Brilliant for Atlassian, painful for the customers.

Another issue is that plugins and integrations do not integrate smoothly. They almost always look and feel like they are just bolted on top. And… as a foreign body managed by someone else outside, occasionally they break. Something that plagues other project management systems with a similar approach like Clickup.

This is a part of a great strategy on behalf of Atlassian, the more integrations are built out with JIRA, the harder and more expensive it is for customers to part their ways. A big, expensive mousetrap.

Let’s Sum it All Up

Here are the true costs of running Jira – facts that Atlassian will never tell you about. When you choose JIRA, it will cost you:

1. Atlassian JIRA Licenses
2. 3rd Party JIRA Plugin Licenses
3. Cost of buying Roadmapping Product Management Tooling
4. Cost of buying Metrics / Insights Tooling
5. Cost of buying BI Progress Tracking Tooling
6. Cost of buying Portfolio Management Tooling
7. Poor UI leading to inefficiencies
8. Poor Structure for Product Management
9. Lack of real-time visibility into progress 
10. True cost of micro-management
11. Teams and Consultants dedicated to managing Jira

Looking at the list above, it’s not a coincidence that lots of companies have been exploring the alternatives. Software Engineering is a significant expense and efficiency and productivity remain the biggest targets for the software development organizations. 

Looking at the list above, it’s not a coincidence that lots of companies have been exploring the alternatives. Software Engineering is a significant expense and efficiency and productivity remain the biggest targets for the software development organizations.

Unfortunately, the true competition to JIRA is quite thin. Thin, you ask? Yes. Its not surprising that JIRA is still considered #1 in software engineering. Others, like Clickup, Wrike, Monday, Asana, and others all tried to go after JIRA but failed. Why, you may ask? Because they all are of the same mold! They just copied JIRA with some minor tweaks to the functionality and a slightly improved UI/UX. Not that those tools can’t be used in Software Development. The challenge is those tools largely pivoted from the Software Development market into becoming solutions to manage projects in other areas like sales and marketing.

So What’s the Alternative?

Today, we live in the world of opinionated software, where different lightweight approaches to software project management are becoming popular. And, these new solutions rapidly catching up from behind.

These new solutions use behavioral science at the team level to drive the best behaviors in the team. Solutions that follow the science of Agile, delivering a quality development process out of the box, without any configurations, with transparency and real-time metrics. And, solutions that gives a transparent real-time assessment of Team’s progress with real-time risk detection that works just GPS of software delivery to really show where teams are and what’s left. Tools that get rid of micro-management and enable teams to do what they do best — get things done with quality and efficiency.

Is there such a tool that does all that? Absolutely, just import your JIRA project and work in a better way!

Sign up and check us out!