Agile transformation? Don't forget about transforming JIRA too.

Yes, I know there are other tools out there.

I’m focussing on JIRA as it’s so ubiquitous and is often customised into an absolute disaster (or, at least customised in a way that is restrictive for a transformation). The sort of mess a JIRA instance can be gotten into is impossible to achieve with the likes of Pivotal Tracker, Trello, GitHub Issues, Asana etc.

I also know that Atlassian have just released their new agile project setup which addresses so many of these points. This is great if you go down the route of setting up a new one (it’s a good practice to in my opinion - the impact of having the issue count start from 1 again to signal we really are jumping off from a new place is far greater than I expected).

Introduction

This is the scenario I’m going to address in this post: You’re embarking on an agile transformation and you’ve already got JIRA. JIRA has always been used to track work items that the developers are doing in your organisation and traditionally there’s been a lengthy and strict workflow in place. A workflow whereby only users in certain roles can do certain things, specific fields need to be completed, custom screens appear at various status transitions and there’s lots of very nuanced different issue types.

You might be making use of Versions and Components to help break out and manage the work too.

You may have realised that JIRA needs to be changed to support your new ways of working, so you’ve created a new project based on the Scrum or Kanban templates, created a simple workflow...and added loads of custom fields to your screens (because you’ve always used them and they “are useful”) and you’ve got a modified permission scheme so that only certain roles have the ability to start a sprint, or change the order of the backlog.

If all (or any) of this sounds familiar to you then I hope the following is of use.

The whole point of this article

As part of a transformation you really REALLY should change the way you see JIRA. For me the crux of the matter is that the tool should never prescribe the way you work, but support it. I’ve seen plenty of situations where this hasn’t been the case: JIRA is used to enforce a desired behaviour, and as such it is customised to make it restrictive, forcing people down the path it has been determined that they should follow (usually not by the people actually doing the work captured in the tool).

Change in behaviour is crucial for any agile transformation, but enforcing the new behaviour through JIRA is not likely to achieve the results you desire. I believe you can tie this back to all of the Scrum values, but in particular Openness and Respect. These are critical for a Scrum Team to succeed (and I’d argue that they apply to any agile environment); your tool of choice should support these values, not impede them.

Let’s look at some problem areas that appear to be common to most companies I’ve worked in that use JIRA (and thankfully let me loose as an admin!).

Shared workflows and schemes

If you’re utilising Scrum or Kanban you have hopefully got a cross functional team that has no dependencies on each other. That means the team of people working together than configure their JIRA project in the way that works for them, with no concerns on whether it is different to another team. But even if there are dependencies this isn’t that big an issue, especially if you follow my advice with regards to Screen Schemes further down.

The long and short of it is DO NOT SHARE workflows, issue type and screen schemes. I’d suggest setting each project up as a unique one (luckily using the default Scrum or Kanban project templates does this already). The benefits of this are that you can make changes to your project to suit you ways of working without impacting anyone else. It gives you the flexibility to experiment with ways of working (supported by JIRA) that are unique to your team.

The one exception to this could be Permission Schemes, if you follow the advice for that (see below).

Restrictive Permission Scheme

Traditionally you’ll find JIRA setup with permission schemes that allow certain actions to be completed by specific project roles or user groups. For agile teams (who self organise and are accountable to each other) I believe you want a flat permission scheme whereby everyone has the same capabilities as each other. Everyone should be able to edit and issue for example, or change it’s rank, or comment on it, or start a sprint.

Each ticket has a full change history on it so there’s no hiding if someone has done something to the backlog item. As such, why bother restricting it what team members can do?

Of course you may want to restrict who can view content to people who have an account (rather than it being open to anyone on the internet), but that really is about it. It’s in this situation that you could share the permission scheme across projects.

Custom Fields

This will be popular. My view is that unless it is required for an integration (which are generally created as part of it) then there is absolutely no need for any other custom fields in JIRA. Learn to use markdown and put everything in the Description field.

I’ve had loads of conversation about this in the past with people; Acceptance Criteria seems to be one of the most popular reasons that people have custom fields. I’ve not heard a compelling reason why it’s needed apart from “we make it a mandatory field so they aren’t missed”. I prefer to trust people and have a team create a Definition of Ready (or similar) which they enforce themselves. Using markdown you can visually distinguish all the different elements you may want to add to a backlog item.

Transition screens

Every time I come across transition screens it’s usually because someone, somewhere, wants to enforce a behaviour of updating a specific bit of information on a ticket. In a traditional setup I’ve witnessed this being used when items are handed off between teams/disciplines. Again, as teams are (hopefully) independent of each other, capable of doing everything they need to with the people that sit next to each other. Given this is (should be?) the case then you’ll find that there’s no need to force such things on people through the tool. They’ll talk to each other, and if they forget they’ll just spin round and ask for the information to be added.

It’s important to understand that if that last bit occurs it isn’t inefficient, its a team finding out what is and isn’t important to them and how they work. It’ll only happen a few times before it becomes habit. If the team is working in an agile way then they are all about the conversations with each other rather than copious documentation.

Hosting & Administration

I generally try to write articles that don't tell you how to do things, but suggest bits you might like to look into. This segment is going to be an exception.

Straight off the bat - get on to a cloud hosted version. Atlassian frequently update JIRA with new features, improvements and bug fixes and you get these for as soon as they are released with the cloud instance. It also means you don't have to pay for a person (or team) to maintain and update your internally hosted instance (and have to raise requests with cost-codes to get your instance upgraded). But that biggest benefit I've found is that it's available everywhere, can have the brilliant mobile app integrated with it and be integrated easily with a plethora of other tools (like Slack & GitHub) which help you really gel with the tool and use it in a far more constructive way. With changes in how people work (remotely, wfh a few days a week etc) this is massively beneficial.

This leaves me with the topic administration. Do not - under any circumstances - outsource the administration of your JIRA instance. There's absolutely no need to and brings zero benefit in the long term. You often have the tool being administered by people who don't use it and just make the changes that they are asked to do, without any regard of the impact the changes can make. Instead, have it administered by a group of people who actually use it - using Spotify's parlance I'd suggest having something akin to a "guild". A group of people who care enough about JIRA being looked after correctly and have a shared set of values so that any changes meet their strict standards.

You don't need many people to achieve this (there really aren't that many requests that come in); invest in training these people up (by people like me) to help make sure they are in agreement with how JIRA should be administered, what their rules are and how people will get requests in to them. These people can then help train the rest of your organisation.

In this setting I've often treated requests a bit like pull requests - whereby you see a requested change but you need to understand why, and perhaps use it as an opportunity to find someone who needs some coaching/mentoring based on their request. Wouldn't that be a novel approach in a transformation...