The human side to scaling Jira: governance, change control, and more

When you think about growing your Jira 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 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.

2. Governance

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:

1. 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.
2. 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.
3. 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:

1. Test all changes in a non-production environment before making the changes in Jira.
2. Have a plan to back out of a change if something goes sideways.
3. 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.