Why Does Jira Suck and What to Do About It
I didn’t learn how to make my bed every day until I was in my forties. Doesn’t it seem odd that in our advanced society I can feel a swell of pride that I make my bed every day and that I can use that to signal my hero status?
Atlassian’s Jira is software that many software professionals would say that they unfortunately are forced to use on a daily basis. Why is it so painful to use and why are there so many complaints about it? Let’s look at some reasons and what we can do about it:
- It’s so customizable that everyone has a different experience with it
- It is easy to use as a means of control rather than a tool to empower
- Teams feel powerless to take ownership of it
- Humans optimize for lowest energy required
It’s so customizable that everyone has a different experience with it
Over the years as the market leader, Jira has changed and is continually adding new features to meet the demands of the market. It has turned into enterprise software which has some upsides and downsides.
As a result, it can do almost anything enterprises want it to do and employees moving between companies are subjected to all the iterations. I’ve been at some companies that used Jira relatively well and others that used it in horrible ways that seemed designed to torment the average employee.
It is easy to use as a means of control rather than a tool to empower
One of the pressures that I’ve seen time and again in tech companies is the management bottleneck. It’s common to have one manager with a dozen or more programmers. When management is overwhelmed, it is common—and I suspect relatively unconscious—for the manager to try to develop systems that offload their work of managing onto the individuals.
The manager optimizes the environment to make their job easier. One such change that sometimes happens is to add required fields to Jira tickets. As this list of required fields grows, it makes the tool a bigger and bigger burden to use with each interaction. This drives more painful experiences using the software and as frustration goes up, the ability to engage with it, stay focussed and perform fast task switching goes down.
Unfortunately the managers optimize for the wrong things. Their efforts to apply controls to make their job easier ultimately make the team slow down and make their job harder. If they recognize that adding controls wasn’t the right way to make the team go faster and reverse the decision then it would be a good experiment. The worst case scenarios is that the manager just keeps trying to add more controls and the problem continues to get worse. I’ve seen entire teams quit companies over this kind of thing. I suppose going from a team of twelve to two is one way to manage the bottleneck?
Teams feel powerless to take ownership of it
It isn’t suffering that leads to hopelessness. It’s suffering you can’t control.
— Angela Duckworth, Grit
One side effect of Jira being so complex is that it’s hard for software teams to gain the skills needed to customize it. There is also an expectation that the way that they are currently using the software is the way that management wants them to be using the software. This may or may not be the case but rarely do teams engage in meaningful discussion about it.
Powerlessness is a defeating thing. Suffering with the software is one thing, but suffering with the software with the belief that there’s nothing we can do about it is something else entirely and is a likely source of the general distain for this software.
Humans optimize for lowest energy required
Why did it take me four decades of life to learn the benefits of making my bed every day?
Wouldn’t it be nice if as a manager one could introduce a new piece of software to their team and everyone engaged with it actively, reading the documentation and actively learning how to maximize the benefits of using said software?
Has that ever happened? I doubt it. There’s always some kind of leading by the nose that seems to be required. We have to go to our cabinet and try to find the best golden carrot to dangle in front of the teams to get them to use it.
I’ve been using various kinds of ticketing software for over two decades and the same problems persist in every iteration. People put the minimum amount of effort into writing their tickets. Even if we put a template in there to encourage them to fill in the details, they manage to fill it in wrong.
We generally default to the lowest energy state. We’re usually trying to find the minimum amount of effort required to do the job. One way that we do that is to see what we can get away with. If no one complains or gives us negative feedback then we subconsciously set the mental bar about what we can get away with.
Fix it with team accountability
To overcome the problem of laziness, we need to rely on our team to hold us accountable to what the true minimum for a good Jira ticket is. This means coming to a clear agreement about the definition of a minimum viable ticket and what feedback loops we’ll use as a team when we don’t meet the minimum.
Minimum Viable Ticket
Jira tickets can be stories, spikes, tasks and bugs. (I’m not sure if other installations have more types of tickets, but these are the ones I’ve seen.) For each of these types the team needs to define what MVT is.
For stories, I generally consider a user story definition (as a... I want to... so that...), acceptance criteria written in a clear format and dev notes that are clear indicators to a developer what the background and starting points are.
For bugs, there needs to be a description, clear steps to reproduce and assessment of the impact and importance.
For spikes there needs to be a definition of the size of the time box, the purpose and the expected outputs. (are we building a prototype, writing up some notes, or what is the spike going to attempt to produce?)
For tasks these are probably more loose but a description and links to related resources seem like necessary parts.
Feedback Loops
Every team is comfortable with different means of feedback loops. With our remote teams it’s tricky to find the right means to give people feedback, especially the you’re-not-up-to-standards kind. This needs to be a discussion that we have with our teams and find out what people will respond well to. If we can normalize giving corrective feedback in a fun way then it will benefit the team tremendously.
Fix it with frustration tracking
Feelings of frustration kick us out of our most productive states. Our companies need us to stay in situations where we’re being our most productive. Our frustration should come from trying to express our ideas and get our creative outputs into the world, not with the tools that we’re using to do our creative work.
Frustration tracking could be a potential fix for teams that have Jira tuned all the way up to eleven and find it difficult to work with.
The idea is to get a piece of paper and every time you get frustrated with the tool, you draw a line on the piece of paper. You could take this to the next level and also write down what you want to do instead. I suspect you’ll see that the your tendency to go surfing of social media is related to the amount of frustration you run into trying to do your work.
If a team tracks all the frustration that their tools are bringing them then it will be a simple way to bring some metrics to a discussion with management about how to better tune the software.
Fix it with honest discussions
Feeling powerless over the software might just be a factor of hidden assumptions that are easily dispelled by having an open discussion. This can be tricky in large organizations because there doesn’t ever seem to be a person who decided things would be this way.
We could take inspiration from the advice that we teach children about how to deal with bullying. We tell them to say “NO” to the bully and then go talk to an adult and tell them. We teach kids to tell someone and keep telling until someone hears them.
Fix it with systems thinking
The problem with optimizing for the wrong thing by management can be solved if we adopt better decision making models. The manager operating from their own perspective is failing to adopt a view of the whole system. Systems thinking is a way of looking at our teams as complex systems and model out how changes affect the system as a whole.
Do you have other observations and solutions?
One way or another, I don’t think the problem with Jira is the software itself. It certainly has bugs and annoyances, but the violent hatred that I’ve seen out there for the software doesn’t have to do with the software, it’s with our experience of the software. There are things we can do to make it better and optimize our tools so that we can focus on creating, because that’s ultimately what makes us happy at work.
Right now I’m working through testing out my thoughts on the matter. I’m curious if you have any better observations and solutions in mind. Please comment and share your thoughts.
