If you have never used JIRA, do not read further. Enjoy your life as long as you can, and start screaming while running away when someone proposes to introduce JIRA to your company.
A Real-Life Struggle
My first contact with JIRA was while working on a project at a customer’s site. A large automotive company based in southern Germany pushed hard to get a vital project straight. To ease our collaboration, we were granted access to their JIRA instance - or at least parts thereof. Here’s what I witnessed:
- Dedicated Maintenance Team: The company needed a dedicated team solely responsible for maintaining the JIRA instance. Customizations, plugins, and integrations demanded constant attention.
- Training Hurdles: Bringing everyone on the same page required extensive training sessions. Employees had to navigate intricate workflows, custom fields, and permissions. The learning curve was steep and hindered productivity. Nothing worked out of the box. Since no one had the time to explain the company-specific rules (and no one knew them), the whole project team was lost in an overarching manifold of possibilities.
I was concerned. None of the ticket systems I had used so far had been so hard to use compared to JIRA. I had a bad feeling about it, but I could not explain why. I thought that maybe they got the setup and configuration wrong. Today, I think Atlassian’s product management is to be held accountable for this mess.
The decision for a specific tool is crucial for your company’s success. You might guess by the title of this article series and my wording so far that I consider using JIRA for tracking issues extremely harmful. Here is why:
JIRA - A Multiverse of Complexities
Let’s venture into the labyrinth of JIRA, the powerful but intricate project management tool. Brace yourself for its complexities:
Editor UI
JIRA’s editing experience leaves much to be desired. Creating and updating issues can feel cumbersome. The unintuitive behavior of its rich text editor and pseudo-markdown editor may frustrate even seasoned users.
If you have JIRA installed, then check your instance. Do people create easy-to-read descriptions? Do weblinks always work? Is code put in a code block? Can you enumerate all possibilities to configure your text editor ({code} macro, Wiki Style Renderer)? Are you sure the text editor configuration is consistent across the complete organization? How many hours did your company spend on agreeing on a text editor configuration?
Issue Types And The Layered Thinking They Yield
Issues or Tickets? Beware! JIRA doesn’t settle for a single issue type. We are pros, right? Instead, it offers a smorgasbord: Initiatives, Epics, Stories, Tasks, and Sub-tasks. Each type represents a layer of granularity, forcing users to map their complex reality into this predefined hierarchy.
There’s a saying, “To understand recursion, you must first understand recursion.” Obviously, neither Atlassian’s product managers nor 90% of the so-called Agile Coaches have the slightest clue about recursive structures.
They do not see how, from one issue or ticket, a complete tree structure of child issues could be derived and that the depth of this tree structure is arbitrary due to the nature of the problems or the tasks they describe - and due to the setup of the organization working on it. However, the designers of Atlassian deliberately decided that each problem on this planet could be mapped into a finite set of categories. It’s a severe crime, IMHO.
Check for the symptoms: If you use JIRA in your daily business, does your thought process become a game of JIRA Jenga? Do discussions devolve into fruitless debates about categorization rather than solving actual problems? Is it a value in itself to have meetings and lengthy discussions to clarify the arbitrary rules for mapping reality into five categories?
I observed another problem: A specific type of person in your organization (mainly managers, especially those who do not have a master’s in computer science or never wrote more than 100 lines of code) will love this system because it comes with a plethora of arbitrary, hard-to-remember, user-definable rules that can be written to a Confluence page where no one will read them. But anytime someone breaks the rules, these people can re-post the link to that Wiki page and feel superior for at least knowing something.
At least knowing something is very important when you have no clue about tree structures, category theory, or the software architecture and programming skills your team needs to craft the product for which the deadline is already overdue.
Consistency Nightmare via State Overload
In their viciousness, the DFH (designers from hell) at Atlassian found another dimension where they could add an even higher level of unnecessary complexity. Buckle up for the state options! A JIRA ticket can have more states than a chameleon has colors. “To Do,” “In Progress,” “Blocked,” “Review,” “Done,” “Awaiting Approval,” and the list goes on. But wait, there’s more! The maintainer of a JIRA instance can define additional states and transitions per project and per issue type.
The problematic part here is that a non-programmer can modify the state machine. Chaos ensues, and ad hoc state machines sprout like weeds. The Dunning–Kruger effect leads people to think they can easily design a state machine with more than two states and more than two state transitions.
Getting these state transitions consistent across projects and issue types becomes a Herculean task. Wait three weeks, find some deviation again, create company rules (do not forget to put them on a Confluence page!), and observe them being broken regularly.
When you try to move tickets across projects, you discover that this fails, or you lose information during the transition. In the best case, you catch the admin of your instance and whisper something nice in their ears so they fix it for you. If not, you have no option but to close the original ticket containing the beginning of the discussion and create a new one within your JIRA section. Problem solved.
Don’t worry, they say. People have absolutely no problem gathering information out of 32 different JIRA tickets, and it never happened that someone fixed an issue incorrectly due to missing an essential, well-hidden detail in one of those Initiatives, Epics, Stories, Tasks, or whatsoever. Unless they do, and the customer with the $10M budget chooses to look elsewhere for people who know their mass from a black hole.
If only those who created the mess suffered the most due to their recklessness. One might get rich by suing Atlassian for all the lifetime lost on this feature.
[TODO: Generate and add a “Lord of the Rings” meme stating, “One does not simply build a state machine.”]
Not Everything Was Bad in the 90s
I am not kidding. Some things and concepts developed in the 90s were quite good. Like e.g. “The Game” or the Matrix film.
Unfortunately, it also brought us State Machines, which were quite popular in the last millennium. This happened because they fit well with object-oriented programming thinking, which was popular, too. JIRA’s initial release was in 2002. Some people probably learned about these topics at university, became managers at Atlassian, and then thought that they knew a thing or two. And now we pay for their decisions daily.
Make a test: People who think that object-oriented programming is modern also tend to believe that state machines are excellent. Avoid these people. Get out of their way and find someone to learn from.
A Light at the End of the Tunnel
Interestingly, no one except managers was using the Atlassian toolchain at one of my customers. Do you see the pattern here? I managed to get Atlassian tools banned within a couple of weeks.
We transitioned to another, much simpler system, and within three months, all tools and development activities were documented and planned without much hassle within the new tool. We also extended the number of users to non-technical staff.
All you need are tools that do not stand in your way but rather boost your productivity. Read more about that success story in one of my following articles.
Takeaway
In the grand theater of software tools, feature bloat often masquerades as progress. But beware, every unnecessary knob, button, and dropdown exacts a toll. Your customer’s productivity wanes, buried under layers of complexity. So, dear product managers, remember that sometimes less truly is more.
Continue with part 2 of this series.
