So you’ve got the Atlassian Suite up and running.  Jira, Confluence, and maybe some other products too, like Bitbucket and Bamboo.  Life is great!

Or is it?

Unfortunately, we often hear from customers that their Agile Lifecycle Management (ALM) suite hasn’t turned out to be the utopia they expected when they first installed it.  This isn’t a problem limited solely to Atlassian products, of course - others, such as Version One and Rally can also prove troublesome to organizations. But today, we’ll talk about some of the problems commonly found with the Atlassian suite of products, and how we address them.

Before we dive into the most common issues, it’s important to look at the overarching issue.  Many clients install an ALM suite and expect it to just simply “work” and solve all their problems.  This, sadly, is almost never the case. Organizations are unique, and ALM tools are purposely designed to be generic when first installed.  They require customization, maintenance, and adjustment over time to perform the way the organization needs - and so the best thing that any organization can do is bring in a team of experts like ours at Agile Trailblazers to help address their needs and issues.

In our years as Agile coaches and tool specialists, we’ve run into hundreds of different issues within team and enterprise ALM tools, but here’s the top 5 that we see most often:

Performance and Stability Issues - Probably the number one issue we hear about from our clients is that their ALM suite is slow, and sometimes unreliable.  This issue can have myriad causes, but most of the time it can be narrowed down to two major root causes: insufficient hardware or misconfigured add-ons.

Insufficient Hardware - Often, organizations will underestimate the system requirements that their ALM tools will need.  Even though Jira and Confluence, for instance, look like fairly simple tools, there’s a lot going on in the background. Even with low user load, the tools are constantly indexing data, running scheduled jobs, and doing other housekeeping chores.  This takes more hardware power than you might think. In some cases, this can be an easy fix - simply adding more memory to a server, for instance, may remedy the problem. Often, though, this just sets up the organization to run into the same problem again in the future as their usage expands.  Instead, we recommend considering a switch to the Atlassian Data Center products, as well as installing new instances with a container framework such as Docker. This allows you to run the products in a cluster, and since the instances are containerized, new instances can be rapidly provisioned and added to the cluster.  Long term, this will set the stage for easy handling of growth, as well as fault tolerance and platform flexibility. A word of caution, though - the Data Center products can be tricky to set up, especially when containers are involved, so we recommend getting expert assistance to do this.

Misconfigured or too many Add-ons - The Atlassian products have a major advantage over competing products in that they have a large, thriving community producing add-ons to handle customizations.  This is a blessing for handling tough situations and providing needed customization, but can also prove to be a curse as far as performance is concerned. The more add-ons you have installed into your Atlassian instance, the greater the risk of performance and stability issues.  If you’ve eliminated hardware issues, the next step is to take a critical look at the add-ons you have installed to ensure they are really necessary. If not, remove or disable them. If the organization really does need all the add-ons, ensure they are updated and properly configured.  And finally, in certain cases you may want to consider a different architectural direction. For instance, organizations often see performance problems arising from bundling their QA activities into Jira using an add-on test management tool. In this case, solutions that link to Jira rather than being embedded within it often solve the problem.  One such example of this is the Tricentis qTest test management suite - it’s tightly integrated with Jira but runs externally, eliminating performance problems.

Over-customization - High up on the list of complaints we hear from our clients is that their installation has so much customization - custom fields, add-ons, rules and policies - that it has become painful to use for all but the most specific projects.  Often, this happens when the organization has allowed project teams to customize the tool for a specific use case, rather than working within an enterprise strategy.

For example, one client we worked with recently had over 20 required, custom fields that needed to be filled out to create a basic issue.  The project teams complained that entering values into all these fields was taking a huge amount of time and making it difficult to rapidly capture user stories.  How many of these fields actually applied to the average project team at this organization? None. Over time, teams had created custom fields and then eventually abandoned them - but no one knew what they were for or if anyone was using them.  Fortunately, we have custom tools that can look at the overall data structure within your Atlassian tool suite and determine where the fields are used, and more importantly, IF they are still used at all. In this particular instance, we were able to remove all of the custom fields from the basic issue type - greatly enhancing the user experience for the project teams - while carefully adding custom fields only for those teams that needed them.

Under-customization - Wait a second - didn’t we just say that over-customization was a common problem?  Yep, we did. But the opposite is also true. Often, we hear clients complain that “I wish Jira could….” or worse yet “Jira can’t do….” - but fortunately, that’s an easily solved problem. As we mentioned earlier, one of the most powerful features of the Atlassian Suite is the add-on framework.  Nearly any functionality that a client might desire can be added through an existing add-on, and in rare cases, we can also create new add-ons to solve unique problems. The most difficult part of this process is finding out what the users need. Often, they will assume that since the tool doesn’t do something, it’s because it cannot do what they need.  The challenge is getting users to ask for what they need. We recommend working with your users directly - observe how they use the tools, and focus on things that seem cumbersome or manual. Agile Coaches are a great way to do this as well - with their greater breadth of experience, they will generally know what is possible. Once you have this feedback, it’s easy to work with a solution partner like Agile Trailblazers to recommend, install, and configure the add-ons that your organization prefers.  In fact, we can even begin by doing the hard work for you via our proven assessment process.

Lack of Visibility - Picture this - you’ve got your Atlassian ALM suite up and running.  Your teams are using it constantly to manage their work. Everyone is happy.  Well, okay, maybe not everyone. Your management is still demanding status reports.  They’re still emailing them to their bosses. Maybe they’re even printing them.

With the Atlassian Suite, you’re sitting on a goldmine of information.  Imagine a world where no one asks for status reports anymore, because they can get the information directly from a dynamically updated dashboard.  Not only is this possible, it’s relatively easy. With a reporting add-on like eazyBI, your users can create their own dashboards and easily share them.  Since they are based on the data your teams enter, they are always up to date and accurate.

A word of warning, though - getting good dashboards relies on having good data.  It’s important to have consistent structures in place for teams to manage their workflow and data.  The dashboards will only be as valuable as the data they rely on. We strongly recommend working with an implementation partner to get maximum value and visibility out of your Atlassian ALM Suite.

Broken Process - This article is about tools!  Not process! Not exactly. Sometimes, it’s less about getting the tools to work for your organization, and more about getting your organization to work - period.

While the Atlassian Suite can be configured to meet just about any process or constraint, sometimes it makes sense to ask if it should do so.  One of the most fatal mistakes an organization can make is to carry old and cumbersome processes into an Agile transformation, and into the tooling behind it.  An Agile transformation, or even simply the implementation of a new ALM tool suite, is a golden opportunity for introspection. Rather than assuming that something must be done because it’s always been done that way, it pays huge dividends to ask “why” rather than blindly implementing processes and controls.  Take it from our experience - if you’re finding it difficult to implement a policy or control within your toolchain, the first question you ask shouldn’t be “How do we do this?” but rather “Should we do this?”

So there you have it - the Atlassian Suite of products is powerful and almost infinitely customizable, and if you watch out for these common pitfalls, you’ll be well on your way to Agile bliss.  But the fastest way to get there is to engage a trusted partner - and we’re here to help.

Learn about how our 140 Point DevOps and Technical Practice Assessment can strengthen your enterprise! Our process involves interviews, surveys, observations and deep dives into your existing people, process and technologies to evaluate the strengths and gaps for enabling the modern software factory.