BA 25/52: A Rorschach Test Or Why We Love to Hate JIRA
From both a professional and an academic curiosity point of view, how can one tool be subject to so much hate and yet is the industry’s go to tool for issue management?
I have never found a logical answer to this question. Rather, I have never found an answer that satisfied my curiosity…until very recently.
Let me share three conversations many years apart at different stages of my career that suddenly opened up a new line of insight into why modern issue management tools attract so much disdain from everyone - coder (engineers, developers, architects) and non-coder community (PMs, TPMs, EPMs) alike.
What do you see when I show you this?
Conversation # 1 - A Long Time Ago at Apple
It was an odd comment. I was running a bug review (aka backlog grooming) with one of the teams that I was the EPM for at Apple. We were in a heated debate about how a particular set of tasks needed to be organized in relevant parent <> child pairing. I was also adding comments to each ticket about what we discussed for said ticket. All civil, nothing too unkind. But, the comment left me with a sense of failure at the time:
Stop trying to turn a bug management tool into a project management tool.
Not having had enough experience or years under my belt, it felt like I had somehow done something wrong. That I was forcing something against the nature of how the software development world worked. I was unfortunately not equipped to understand the profoundness of the meaning of this comment. Alas, I laughed, brushed it off, filed it in the hall of memories in my brain, as we all do with such experiences.
Conversation # 2 - A Few Days Ago (Not really, but recently)
When I look at Jira or any set of work, all I see is a list of tasks to complete. I don’t see epics, stories, just a list of tasks I need to get done. How they come together is a design that I understand.
Trigger: Memory recall activated. This conversation had the hallmarks of a conversation I had many seasons ago. But what does this mean? This time however, with some many more years under my belt, I am wiser (older, got some grays’ and bald spots), the inquisitive mind had some training so I began to probe and ask more questions.
Do you not pair things into parent <> child relationships? Not always. I need to focus on writing code.
How do you know what is the totality of the work to be done for a feature? The list of tasks is the work to be done.
What is a feature to you? Features in the design doc don’t always translate into neat clean groups. How do you breakdown an API you need to build. I know I need to build API but again just a list of tasks to get through, lines of code I need to write.
I had more answers that I didn’t before to shed light on the comment at Apple many moons ago. I was intrigued.
Conversation # 3 - 12 hours ago (not really but very very recently)
I, as an engineer, only see a list of tasks and that's all I want to see. But, I understand that Aadil needs to show progress towards a particular objective and their (TPM) work revolves around leveraging reports and tools to synthesis these tasks into views that leadership can understand.
Wait… hang on… I have seen this movie before somewhere… is this a sequel… remake…. wait wait wait…. light bulb… follow me dear reader, I have a working theory.
A Systems Thinker, 3 Conversations, A Working Theory
One of the most magical things about operating in the Systems Thinker mode is that it teaches you to examine what is in front of you in a holistic manner.
See it at the 10,000 feet view, then zoom in, then out, then zoom in on a different part, zoom out again, keep doing this until you understand what it is that is in front of you.
Perhaps the fundamental flaw of all modern issue management tool is molding the engineering view to fit the needs of the leader or project management view.
Perhaps the hate comes from the fact that the tools fail at achieving the needs of either class of users. What you have is a tool that is jack of all trades, master of none.
Radar, the custom issue management tool used internally at Apple, operated as one big backlog. There were no sprints, epics, user stories, portfolio initiatives, no kanban views, boards; teams was used for permission, there were no projects, we operated around releases; instead of projects or teams we had components that reflected the components of the iOS stack. Its fundamental approach in my point of view was that teams are organized around work.
Similarly, at Google, when I was part of the Android Things team as Program Manager, the custom Issue Tracker tool was designed around Components and Hotlists. There were no projects or roadmap views or kanban boards.
What do you notice that is common between these two tools? These are tools that are designed with a singular customer/user/stakeholder in mind: developers. There is no scrum fluff, there is no agile SAFey philosophy about them. In my not so humble opinion, they are at their core fundamentally focused on the the way the engineers view the world - a list of tasks that belong to a component of the architecture, software, platform.
In both of those tools, us TPMs had to spend time and energy to synthesize answers around the project management questions for leadership but we did it without intruding in the space which the engineers needed to operate and live day in day out to keep track of the progress they needed to make.
The closest I have ever seen to anything remotely like these two tools: GitHub Issues. I have used Jira in the past. Fuchsia team at Google used Jira. When I transitioned to the role of Program Manager for the Dart Lang team at Google, an open source project, GitHub Issues (Project Classic) was the tool of choice. It was wildly simple, basic, utilitarian, but again organized and built with the developer in mind.
Put aside the performance and quality issues with Jira at scale, I believe it is not a tool designed for engineers, and it is not a tool designed for TPMs - it is a tool built for a Software Product Engineer Project Developer Manager… who doesn't exist. They support every customer class, every new agile methodology, faux customizability, decimal story points, I mean everything yet at its most fundamental core, its a broken tool with odd design choices (ever try managing labels in jira.. go ahead, I will wait) that helps no one. Yet, it is the tool that is most commonly used in the industry.
A Solution? An Alternative…
Look, I am sure there are teams and organizations out there who have found success with Jira, by operating in a world view that Atlassian believes you need to operate in. I am happy for said organizations and teams. I am double sure that the powerhouse of products that Atlassian offers is loved by many.
I also believe, Atlassian is too big to fail or be challenged. However, there are two alternatives that give me hope of a better world:
Linear
The new GitHub Issues
Linear at its core is a faster, nimble, declutered, hyper focused Jira (the primary issue that I have, no pun intended… is that a pun?). But, their secret sauce is how they are approaching the concept of Projects and Milestones in their Roadmap feature. Their implementation represents a more closer view to how software development teams operate in a truly cross functional world.
GitHub Issues, the new one that was just announced post Microsoft acquisition, is taking the brilliant simplicity of its classic issues tool and adding the ability to build views on top of the main backlog of issues rather than modify the original source. The Achilles heel for this tool however, I know no developer is going to be excited about having non-technical teams operating in GitHub for task management so it is something a tool that can't be used universally like say Asana.
Why should I care about all of this?
This matters to you, TPMs, because at some point you maybe looking at replacing Jira, or figuring out why Jira is not working, or tasked with finding a better way to report on progress, or leadership is not getting the answers they need like “are we on track for a given release”.
Before you rush off and start trying a whole bunch of things, you must look at the whole system at your organization, the processes, the flows, the actors (engineers, non-engineers). Such decisions or solutions requires a collective approach.
What took me years, close to a decade to understand, I want you to have a head start on: what you see when you look at an issue management tool and what engineers see is vastly different. A solution for you is a pain point for them and a solution for them is not useful for you. Finding the balance will be difficult and contentious but possible. Start with what matters to each stakeholder.
So, when the day comes and you are asked to step in to resolve such situations, your starting point and primary question to all the stakeholders impacted by said decision needs to be…
What do you see when I show you this picture?
Good luck. Until next time 👋!
-Aadil
How was this week’s newsletter?
I used to be a big believer in the "one tool, one source of truth" approach... but as organizations grow and needs evolve I now think you need tailored tools sharing data (truth) elegantly across the org. Jira tries to be all things to all people - but it ends up being not enough for anyone.
Really great breakdown of Jira. I always start by telling folks what Jira can't do. Jira can't read your mind, so when you have updates put them in (a pain point!). Jira can't make anybody _do_ anything, so when you create a ticket for another team you have to tell them why (don't "weaponize" Jira).