Is your Jira in need of a cleanup?
Are you like many other companies using Jira, but have found that it’s not working as good as you would have hoped and hasn’t been widely adopted, with some teams refusing to use it?
If so, I’ve got some questions for you…..
Has your company experienced any or all of the following:
Different people have tried setting Jira up for their project/team, but it seems to work differently than the others, which is confusing for team members that work across projects.
When someone makes a change to the configuration for a project, it tends to be a hit and miss approach as they try to figure out the right setting to make the changes they want, which can leave a mess behind.
And then it’s discovered that some of those changes have negatively impacted other projects, e.g., a change to a status for one project which impacts all other projects that use that status.
Because projects are configured differently, when issues/tasks need to be moved from one project to another, it is difficult as the projects aren’t compatible. Also, it is difficult to provide a view of issues/tasks across those projects due to those differences.
There are various add-ons that people have added over time (which has added to the cost), but it’s become harder to know what to use for what situation.
When projects are initially created, a lot of the time, it doesn’t work as required and takes time (and missteps) to get it working correctly.
If you answered yes to any of the above, don’t be ashamed as you aren’t alone - there are lots of other companies out there facing these and I’m often asked to come in and sort out the issues.
So how did we get to this point?
Atlassian provides a suite of integrated tools, such as Jira and Confluence, that are used by hundreds of thousands of customers and millions of users. A range of 1st and 3rd party add-on’s are available in the Atlassian Marketplace that extends the functionality even further. While originally commonplace in software development teams/companies, Atlassian’s products are gaining popularity in other types of teams/companies, particularly due to its support of Agile practices.
A factor that has contributed to the rapid growth of Atlassian’s customer base is its strategy of making it quick, easy and cheap to get customers signed up, creating projects and adding team members, which then spreads through the organisation. As this happens, the licence cost jumps from the initial low cost to a significant sum, which by the time that someone picks up on this, many teams are using the tools and don’t want to give them up. Note that I’m not just picking on Atlassian here - this approach is widespread among software companies to accelerate their growth.
But the problem with this approach is that to make it so easy to get up and running, a compromise was required: each project, when added, has its own unique set of configuration schemes. If you have 10 projects, there are 10 unique sets of configuration schemes. I’ve seen instances where there are quite literally pages and pages of configuration schemes.
The other problem is that the configuration is not simple; there are many ways to configure Jira, but it often comes down to one that actually works. Without a deep understanding of the configuration (I’ve been doing it for 15 years and am still coming across new things), users will fumble around, using a hit and miss approach of trying to find the right setting. They will often mistakenly make a change that negatively impacts other projects. This results in a mishmash of configurations and settings, with projects working differently, confusing users, especially where they work across projects. Sound familiar?
Another thing that I have come across a number of times is where a company tries to identify the right tool and find themselves going from one tool to another, as they don’t seem to be able to get them working. The fact is that there is no one perfect tool, and it’s difficult to know which one is going to work the best - somehow you need to figure this out by looking at the various product and feature comparisons, which don’t help at all to understand what it will look like in your company. I’ve seen situations where companies have multiple tools because each department has chosen its own tool. You can then only imagine what it’s like to collaborate between teams when they are using different tools.
I would suggest the following reasons why this happens (and this applies to other tools out there as well):
The person setting up the tool isn’t experienced in the tool, how it is configured and it’s quirks and limitations (every tool has these)
Often it’s started at the team or project level, with no consideration how it’s going to support other teams and the collaboration between the teams.
Think of your business as a complex set of processes. As you would get an architect to design your house, the tool needs to be architected through the configuration to support those processes and the structure of the teams. While you could just do team/project by team/project and hope that they all work together cohesively, in reality, that approach rarely works. Again, you wouldn’t build a house a room at a time and then add them together like a jigsaw puzzle, ending up with doors that open to a wall… The other thing you should do is make sure that it can scale with the organisation as it changes.
I have been brought into a number of companies to rearchitect, reconfigure and clean up their Jira systems so that it works more effectively and is easier to use.
So what can you do about it?
These are the things I would typically do:
Review existing projects to determine what each project is being used for and what configurations are actually being used, e.g., statuses, fields, issue types, etc
Determine the base set of configuration schemes that cater to the requirements and then consolidate the existing configurations. Note that this also means when a new project is added, it uses the appropriate configuration scheme, which means it will work as required as soon as it is created. Also, it means that it avoids the problem of additional configuration schemes and the problems associated with that.
Archiving projects that are no longer being used
The other value-add things that I will often do include:
Allow for cross-team/project collaboration and views across teams/projects.
Where a company wants to adopt agile practices, setting up Jira to support those practices, then coaching the teams
Wearing my process hat, thinking about the processes and better ways of doing things. The magic is where you find a better way of doing things, (i.e., the processes) and set up the tools to support those processes.
I’ve got a lot of experience in using Jira (with the right addon) to support project management practices (managing schedules and resource management).
Of course, you could have a go at doing this yourself. But realise my ability to do this is from 15 years of working with Jira, implementing Jira for a range of companies and understanding it’s “quirks and limitations”. Also, I have done many cleanups and have come up with a procedure for doing with as well as a number of techniques to make it easier and quicker.
Or if you are a company thinking of implementing Jira, I can help set it properly right from the start, avoiding these issues altogether, which will save you a lot of time, resources and avoid the frustrations of getting it wrong, allowing you to focus those resources and building products.
What have our customers said about it?
“I think one of the biggest things we gained from this is starting on our journey with Jira and Scrum - with someone who actually knew the tool and operationalisation of it!”
If you are experiencing similar issues with your Jira, get in touch with us now.