I’ve been suffering using Atlassian Jira for more than 20 years already at this point, and I have seen a fair share of patterns and antipatterns (that’s Japanese for “fuckups”) and, being the new rambling old man, I feel entitled to spread my dystopian views on the pages of this publication you’re reading right now.
Jira was born while everyone was still in shock commenting one of the hottest articles of the early internet, namely “The Joel Test: 12 Steps to Better Code”, which, had Hacker News existed at the time, it would have stayed on the top 1 position for a few months (well, I guess it topped at Slashdot, which was what cool geeks were using 25 years ago). You have no idea how popular (or vilified) this article was at the time.
So Jira comes along in 2002, and a lot of companies wanted to increase their score; so they started adopting things in order: first, source control, usually CVS or Microsoft SourceSafe to begin with, with some adventurous souls diving into the current betas of Subversion, still in heavy development at the time.
(Kids: Git wasn’t even a plan yet.)
Next in the list came points 2 and 3, the making of a build in a single step, and repeating that every day, which today are tasks mostly delegated to some Continuous Integration system, many of which being provided by the same platforms that give you source control (like GitLab CI/CD, GitHub Actions, etc.)
And then, of course, came point 4 in the Joel Test: “Do you have a bug database?” The problem with that question is that there was no clear answer in 2002; there was Bugzilla, but it was notoriously hard to install and run (at least back in the day), and not that pleasant in terms of UI design. Some others tried to use Excel or Access for that purpose (I’m not kidding, seen that, left right away). Companies who are not in the business of running bug tracking systems don’t want to spend much time with such a thing; so Jira came quite handy, effectively eating a whole market overnight.
Atlassian Jira didn’t come alone, of course; the power of synergy between software packages is very evident when considering its eternal complicity with Confluence, another package from the same company that has become the de facto standard wiki for companies nearly everywhere.
Jira was released one year after the proclamation of the Manifesto for Agile Software Development, and the rise of Scrum as the all-powerful methodology that all teams in the world use to release unusable software.
At the core of Jira lies the most obvious and simple of features, namely the tracking of bugs, or more generally, things-to-be-done. So, as Agile came, Jira evolved; it isn’t uncommon nowadays to see Jira installations with the famous “Kanban plugin”, with esoteric customizations of all kinds.
Because Jira is famously flexible: you can define ticket types to accommodate any kind of semantic organization of your stuff, following any process you can imagine, like the classic “Bug” and “Feature”, but also including stuff like “Task”, “Story”, “Epic” (SAFe practitioners rejoice), “Work Increment”, “Issue”, or so many other things.
Then you can organize workflows for those types of things, with their statuses very rigidly going from “Open” to “In Progress” to “Demo” to “Support” to “Maintenance” and very, very rarely, to “Done”, and you can even view a graph that show such transitions between statuses, so that you understand the following dialog:
– Hey I fixed this bug, but I can’t set the ticket to “Done”.
– Of course you can’t; first set its status to “Review” and assign it to someone in QA. If approved, only they have the rights to then set it to “Maintenance” which will trigger a deployment pipeline and a message on Slack for the nightly release team, which will eventually set the ticket as “Deployed”, triggering an email update to the PM, who will set it to “Done”… eventually.
(Of course, for some reason some PMs never perform that last step, so now you have a “backlog” of tickets in “Review” state, longer than a novel by Marcel Proust. Oh, and guess what: the bonuses of the poor developers at the starting blocks of that food chain depend on the number of tickets with “Done” status. Good luck, kid.)
Jira also allows you to create Kanban boards for those things, and of course, your boards can have 10 or 15 columns, not only accommodating those weird ticket status workflows of yours, but also your team structure, roles, and whatever other taxonomy you could come up with. Good luck scrolling those on a mobile device. (Wait, why do you even try to use Jira on a mobile device?)
Oh, and did I mention that you can extend your ticket types with an insane amount of metadata and new fields, which nobody understands their purpose but are mandatory for whatever reason? Raise your hand if you’ve spent 20 minutes asking around how to properly file a bug on the company’s Jira.
Insert madness emoji here.
In an ironic twist of fate, the same Joel Spolsky at the origin of the Joel Test kickstarted in 2011 a tool that was supposed to provide a saner alternative to Jira, called Trello, which became wildly popular for a short while in the mid 2010s.
But guess what happened? Well, Atlassian bought Trello in 2017, and yes it still exists, but no, I haven’t seen a single team using it in the past seven years. Too bad.
(Honest question: is anyone using Trello these days?)
So, here’s the thing: the best software organizations using Jira I’ve seen in the past 20 years do not (hear me out) do not customize Jira to such extent. They don’t create Kanban boards with 200 columns, nor have 30 ticket types with a crazy status workflow for each one of them.
The most effective software organizations I’ve seen have a Kanban board with just 3 columns: “Open”, “In Progress”, and “Done”. There are no restrictions on who can open or move or close tickets, and they certainly also have just two entry types possible: “Bug” and “Feature”. Oh, and they don’t use crazy forms with mandatory fields for their entries; they have, however, the good habit of writing extensive descriptions on them, without exception.
That. Is. All. Don’t go overboard with Jira, seriously. It’s a useless and painful idea, and it will hurt your ability to release good software. It can even become the reason why so many of your engineers leave the organization in disgust, or why you’re releases are always so (ironically enough) buggy, and late to the market.