When you think about growing your Jira Software instance what’s the first thing that comes to mind? Performance factors? Tactics and process?
While all of these are critically important, and we’ve written documentation on what considerations to make when scaling, I’ve come to see that the human element to scaling is just as important – and often the most overlooked – part.
At Atlassian we place a lot of importance on people and culture. We believe that understanding how your teams work together and develop processes offline before mapping the process to your tools will better set you up for success.
This is no different when scaling Jira. As a Technical Account Manager, I’ve helped many organizations grow their Jira instance, each at a different point in their journey. While there are countless combinations of factors that make your scaling story unique, I’ve found a few best practices of a more human nature that can mitigate some of the most common headaches. Let’s talk about some key practices to consider:
1. Limiting administrative access
When granting or changing who has administrative access, ask yourself this question: When a request comes in, will this person make a decision with the entire instance in mind? Limiting global admin access to those who have a holistic understanding of the environment helps prevent the wildfire growth of new changes, some of which can unintentionally have a negative impact or slow down other teams. Having a core group of admins that know each moving piece and its effect ensures each change is made with consideration and has a beneficial purpose.
In Jira Software 7.3, we released new Project Level Administration features that put some of the admin power into your project administrator’s hands without giving them the keys to the kingdom. Since then we’ve built out more features and will continue our focus in this area to help spread the load of supporting a growing user base. Whether Project Level Administration is right for you will depend on your audit requirements, standardization efforts, and internal policies.
I can’t emphasize this one enough. Writing down rules and guidelines, or governance documents, ensures admins are on the same page with configuration and change control. At Atlassian, we write these in Confluence. When new people come into the organization or someone leaves, the Confluence documentation remains constant. Here are some helpful hints for creating documentation:
- Clearly think through and state the intended use of the system. For example, if Jira should not be used to store documentation as attachments, be sure that’s written.
- Look towards standardization as a means to help manage growth. This might mean an agreed-upon workflow or custom fields and screens. This should also include things like integrated apps. For example, if one team wants to use Portfolio for Jira while another wants to use Structure, work to find a compromise. Be intentional in your documentation. Explain when a new app or integration should be considered and include the evaluation process.
- Consider having “template projects” that you can clone to not only reuse existing schemes but also to help encourage standardization across teams looking to do the same type of work in the system.
The main thing to keep in mind when developing governance is to gain an understanding of what teams need and want out of Jira and think through the best way to move forward as a whole. Standardize where it’s important and allow for flexibility where possible.
3. Educating users
Scaling usually means more users are continually being added to Jira. And this often equates to more requests sent to your support team. We believe it’s critical to have onboarding documentation so that new users start on the right foot, know the intention of Jira, and exactly how to use it. Atlassian provides online classes, live team training, and tutorials through Atlassian University, so you can rely on us to do most of the heavy lifting that comes with training.
User education shouldn’t stop at onboarding. Regular outreach in the form of internal blogs, Company User Groups, or lunch and learns are a great way to keep your users engaged and up to date on best practices. It also gives them a forum to share the ways they’ve used the Atlassian tools to unleash the potential of their teams and do their best work.
4. Change control: seek first to understand
When it comes to implementing changes, don’t just rubber stamp any and all requests that you receive, but make sure each change is beneficial to users and an appropriate fit for the environment. In other words, always get an understanding of the “why.” This applies to changes like adding more workflow statuses and installing new third-party apps or integrations. Here are a few more measures to take:
- Test all changes in a non-production environment before making the changes in Jira.
- Have a plan to back out of a change if something goes sideways.
- Include change control in your governance documentation and reiterate that best practices should be followed to ensure changes don’t get out of control.
Let’s take a deeper dive into an example of change control: custom fields.
Often, users will make a change request, like asking for a new custom field, because they know that Jira is configurable and flexible so it seems like the best solution to the problem. Instead of simply saying yes, seek to understand the problem first and then work together to determine if another field is the best solution.
Do they want to add a new field because they don’t like the name of an existing field that serves the same purpose? In this case, it’s probably best to say no. Will this new field ever be queried against with JQL or used as an important metric? Always consider the necessity before saying yes, and make sure you’ve thought through all possible solutions.
To limit the number of asks received, some simple user education around the core features of Jira can go a long way. It will highlight options that your team may not have been aware of, and enable them to address the problem on their own, without creating anything new at all.
As the number of issues in your instance grows, so does the index. This can create clutter for your team if they aren’t narrowing down their searches enough. Consider whether or not a retention policy needs to be implemented and whether or not archiving is an option for your instance. Removing no-longer-needed issues keeps Jira tidy and easily searchable, and can help to avoid performance problems related to the sheer volume of issues accumulated.
6. Configuration tweaks
Each instance has unique configuration considerations that are good to review on a regular basis to see if improvements are necessary. One of the best ways to identify where configuration tweaks are needed is to work with Premier Support and run a Health Check. During a health check, Premier Support will look for known issues with configurations, compatibility, driver versions, performance conditions, memory settings, and other improvements. This is very useful in preventing production outages and slowdowns and helps ensure success during a system upgrade.
7. Choosing the right platform
If your instance is not already a Data Center instance, determine if it’s time to make the move. Data Center works by spreading your user load across multiple nodes to help maintain performance as the instance scales. In addition, it may make sense to route REST traffic to a specific node so that user-facing nodes aren’t impacted by heavy automation calls. Plus, Atlassian now offers Data Center deployment options for Jira Software on Microsoft Azure and Amazon Web Services which can help to remove infrastructure set-up barriers to scaling.
8. Focus on people and process
No matter where you are in your scaling journey, placing importance on people and process in addition to technology and performance will help drive success. It’s helpful to seek first to understand how your teams work, develop a process, and inform users by writing things down in an accessible place. Want more personalized help scaling your Jira instance? Get the help of a TAM.