Many Jira administrators emphasize how valuable Jira is for process enforcement. But sometimes process isn’t enforced because changing the process improves the product or service that we are delivering.

How does this come up?

I use “reference” projects to articulate how we use Jira in our organization. I have one for each kind of team we use (where we have consistent team structures).

When I create a new project I use the appropriate reference project to get the new team up and running quickly. When I show them the project, I tell them to start with this. Then, if they need any adjustments specific to their team, they can ask for them and I’ll review them with the governance team.

Is the team asking for the adjustment consistently shipping product?

This is a minimum ask I use to qualify teams that are tweaking process because they don’t understand how our organization does its work.

This sounds judgmental… because it is. We modeled the reference projects around how we work and how our teams work. If a team asks for changes to a project as soon as they start using it, that’s usually a sign they don’t understand how their team’s work relates to how other teams are doing work. If they’ve got a history of shipping product it’s much easier for them to ask for changes that fit into how we work as a whole organization.

Does the change they would like contradict our values?

Making a better product is hard work. Sometimes dramatic changes to how we do our work is required in order for customers to see dramatic improvements in our projects.

I have found that the weirdest requests from product teams are tied to how the team is thinking about what they are creating in a different way. Changing how you think about the problem you are solving is one of the most valuable ways to improve your product.

This is where the governance team’s judgement is more optimistic. What heights could this team achieve if we configured our teams around this new idea?

In these cases I find it’s best to be open to dramatic changes, but to guard against changes that contradict our values as an organization. For example, our team may work in a regulated industry, in which case processes that ensure security and privacy are valuable. Perhaps we develop products that, if poorly implemented, could cause injury or death. Therefore our values include (years) of thorough testing and rigorous review.

Orienting our team’s specific changes around our values allows us to:

  • Accommodate all kinds of improvements to how our Jira configurations work.
  • Reinforces that how we work is driving how we configure Jira.
  • Make our values more tangible for our teams, allowing them to improve how strategically aligned they are in their work.

Is the change requested going to be maintainable in Jira?

Finally, not all changes requested are actually easy to maintain in Jira. The harder Jira is to maintain, the more likely we are to tell people we can’t make dramatic changes. To find the right balance always try out the configurations in staging and show them to your team. By including the team in the conversation about maintainability, it’s usually very easy to design for the right balance between specific team customization and the configuration of the whole Jira instance.

Sometimes the change being requested is not actually appropriate for Jira at all. For instance, if you have a good Continuous Integration / Continuous Delivery practice (using Bamboo and BitBucket) you probably want to automate enforcement of security and configuration requirements in the CI/CD plans.