You Are The Problem: Stop Blaming Jira

It finally happened! I read my 100s article about why Jira sucks and we should all go back to using sticky notes on whiteboards or draw gantt charts on cave walls or whatever. Just anything else that isn’t a modern productivity/project management tool, because those are evil <hisssss!>.

I understand, I truly do. Anyone that has been working long enough as a software professional, has experienced by now one form or another of the horrors of corporate born bureaucracy.
We all experienced one of those endless tickets and approvers loops, seemingly there just to create ass-covering paper trails for every single decision being made.
We all felt at some point like we are spending more time updating and documenting what we are doing, rather than actually doing the damn thing. And we all probably saw first hand what it feels like when everything that we do is asked to be closely watched by some ingenious boss, that just found another way to express their need to micromanage.

But despite all of us going through some or even all of those experiences. Same as the proverbial Pavlovian dog, we seem to associate our horrible experiences not with the true causes that led to them, but with the tool that was used to subject us to the punishment.
Or in other words: It’s all Jira’s fault.

Well I’m here today to tell you my fellow tech people:
Jira tickets don’t kill productivity: People kill productivity.

Tickets, bullets and other tools to manage people

Let’s start with first principals: Never blame the tools. Tools are just tools. You can do wonderful things with a hammer, and you can do horrible things with it. Like any tool, you need to have an intent behind using it and be skillful when using it, if you want to get the right results. Blaming Jira is like blaming the toaster for burning your breakfast instead of admitting you simply suck at making toast.
It’s not Jira plotting against you, it’s the people wielding it.

Which leads us to the sad reality: In the corporate environment you can weaponize nearly anything.
I’ll be the first to admit, that in the list of tools commonly turned against the people using them, Jira and other types of project management applications are high up there.
Which obviously leads to the question: Why are we doing that? or even more importantly, Who should we blame for that?

Method, Malpractice & Malice

When analyzing something that is grossly not working in the organization, I like to think of Hanlon’s razor with my own personal addition:

Never attribute to malice that which is adequately explained by malpractice (or stupidity). Never attribute to malpractice that which is adequately explained by the dictated method of work.

Most companies are at an ongoing battle of self improvement. But there are a lot of conflicting needs to make a high performing tech organization.
You want to give confidence to stakeholders about your long term plan, but you also want to be agile and react to opportunities as they come. You want to understand how things are going so you can course correct and remove blockers, but you also want to give people agency and allow creativity. You want to have predictable deadlines for delivery, but you also want to keep technical debt at check, have time to innovate and keep your people happy.
The list of conflicts go on and on.

That’s one of the key things that lead to the agile revolution. As well as the myriad of work frameworks, methods and almost cult like belief systems that sent organizations around the world in their search for a silver bullet to solve all these conflicts.
Who can blame them? Scaling engineering operations or any other type of high stake technically centered operation, is simply hard.
If your company decided to use SAFe® (yeah that’s a real freaking trademark sign there) as a method to manage day to day work, it’s because someone truly believed it will help the company perform better. Even if they didn’t completely understand what they signed into, or even fully read the manual before starting to make changes.

And that’s where the malpractice starts.
Same as how tools won’t save you, no work methodology will work if you don’t have an inherent understanding of what it is good for, how does it improve things, and does it even fit your organizational needs to begin with.
Many managers are lost or simply lazy, and just end up implementing work methodologies, paint by numbers, without thinking of tradeoffs or inherent value.
Epics, Stories, Tasks, Initiatives, Daily meetings, weekly planning, weekly pre-planning, bug reviews, backlog grooming, mid quarterly review, quarterly planning, scrum board, kanban board, roadmap board, gantt fake-delivery-lets-lie-to-ourselves-and-change-it-every-week board.
For many companies the day to day work framework feels like badly built IKEA furniture that was assembled without any instructions.

Daily Scrum meeting circa 10,000BC, before the invention of Jira

Want to know if your company or team are intentional or not in the way they do things?
Simply ask: Why? What are we looking to achieve? How does our methodology serve to improve or help measure our KPIs for success?
If we open tickets for everything that we do in Jira and need to update the status all the time, why are we doing it?

There should be a good answer, or at least a coherent thought behind it.
There should be a clear direction to how reviewing task boards as a team and dragging things from one side to another improves productivity or at least communication and transparency.
There should be a clear reasoning to how using tickets is improving our work, or at least how it can help us measure our improvement.
And this is the place where you find one of the biggest gold mines of management malpractice known in the tech industry: the way we quantify our agility, productivity and quality.

We all want to be data driven, we all want to make informed decisions. But just because you can measure something, doesn’t mean it’s the right thing to measure.
Does number of tickets closed within a time period mean anything? Probably not. Is the mean time taken to handle a ticket meaningful? Very rarely, at least in software engineering. But they are both very easily measurable, especially if you are willing to devote people’s time in maintaining them.
It’s those misguided cases that often turn Jira and the likes of it from being the productivity tools they were meant to be - to getting the reputation of being corporate weapons of mass distraction.

Our office life could be this, but you insist on using Jira

Alas, if you’ve found that the methodology used by your team is justified, and your manager knowns what he/she are talking about with their intentions and implementation of said methodology, there’s only one explanation: Malice!
Right?

Maybe…
Your boss might be a control freak that just wants to figure out ways to micro-manage every hour and day of your work. They might want you to create a paper trail that can later be used against you for whatever reason. Maybe they just want to keep you busy doing things other than work, so they have excuses to hire more people.
But before you put on that tinfoil hat and yell “I knew it!” at the screen, maybe it’s worth taking a step back for a second.

The Realities of Productivity at Scale

Scaling software operations effectively is hard. The bigger the project, the more people involved and the more tangled the dependency web between moving pieces - the harder it is to navigate things. It’s like the difference between turning a speed boat and an aircraft carrier.
The past also has a weight, and depending on what you are building so does the future. Simply being able to remember all the things we wanted to do and still want to do, prioritizing them and picking goals, can be a daunting task at some places.
Sticky notes on a whiteboard are a great novelty, they are simple, tactile and to the point - but good luck on scaling that, especially for a large globally distributed team that has been running for some time.

Now I’m not going to sell you Jira here or anything.
Jira is far from being a great tool. It can be extremely complicated, even over complicated at times. It has aging UX and a ton of weird quirks that bug the hell out of a lot of people. But most of all it’s bloated to the brim with features to cater for any type of work management framework known to men.
If you ever tried to administer an instance of a cloud Jira account, or god forbid Jira server, you would know what I mean it when I say that it’s a tool too configurable for it’s own good. It really seem like it can barely sustain it’s own weight in features, knobs and switches. I truly can only feel sorry for the team maintaining it in Atlassian.

But with all that being said, Jira has one thing going for it - It became an industry standard in many ways. It uses a common language most software professionals understand and share, and that’s a lot.
Trust me on this when I say, that when it comes to scaling software operations - having a commonly understood language and shared standards is the only way not to go completely nuts.

When used correctly, project management tools can help orchestrate projects across many teams and people. It can help people not forget things they otherwise would have, understand priorities without consistently double checking with others, and even promote individual’s agency.
It can automate transparency for cross level or high level progress by aggregating the status on important projects, allowing faster decision making for managers, without having to set unneeded meetings or take people out of their focus time just to get an update.
Like any good tool, it can do wonderful things, if you simply use it the right way and with good intent.
But yes, it also means you need to update the status on that story you’ve just finished, otherwise all that simply doesn’t work.

That’s where many times things slip. It’s not malice or malpractice or even the method. It’s the inability to create the shared understanding that in order to make complicated things work, there are some sacrifices that need to be made.
It’s like traffic laws or taxes or the office dress code. All sacrifices that are made in uniform for a bigger cause that should benefit all in the bigger picture.
Small sacrifices, like using the right tools in the right context, to automate things like orchestration, transparency and status monitoring - are usually the lesser of all evils.
Unfortunately when organizations fail to explain that to people, they end up trying to forcefully integrate these tools and practices into the day-to-day work regardless. That’s where it usually becomes dogmatic and feels to many like an unjustified punishment.

Is this Scrum or Kanban at this point?

It’s never about the tools.
If you go back to the agile manifesto, it clearly states:

Individuals and interactions over processes and tools

We tend to forget that. Both managers that got hooked on some new productivity framework or engineers that are frustrated by another ritual.

When we are blaming the tools it’s usually a sign we forgot the important parts. The people, the interactions, the things we are actually trying to achieve together.
Tools like Jira and the ways we end up using them, serve only as a reflection to who we currently are, what is still not working well for us, and what we can do to improve on that.