Andy Kelk

Digital Technology Leader

Why all the Jira hate? I’ll tell you why

I’ve recently retweeted a few tweets which weren’t exactly complimentary about Jira. For example:

Today a co-worker asked me why I was so down on Jira. Which is a fair question; especially since we use the entire Atlassian suite of products including Jira. So why does Jira set my teeth on edge?

The biggest reason is that there’s somehow become a conflation between using Jira and “doing Agile”; that is, many organisations seem to think that gaining agility is a matter of installing a tool. Of course, “Individuals and interactions over processes and tools” would have you think again; but maybe hoping that people have read the agile manifesto is a little optimistic .

Since Atlassian renamed the Greenhopper plugin to “Jira Agile”, the situation has only got worse. What you now see is still a “project” that is composed of “issues” but they’re magically displayed in swimlanes. So now we’re Agile, right? The thing is that Jira started life as a bug/issue management tool; and if your primary unit of work is an “issue”, you’re not starting from a great place . (As an aside, every time I hear a team talk about their user stories or features as “Jiras” a little piece of me dies inside).

You can see the impact this has had on organisations by looking at what skills they’re seeking in their job ads. Project Managers with MS Project skills have been replaced with “SCRUM Masters (sic)” with Jira skills.

The second way that Jira promotes bad practice is in its workflows. I’ll admit that it’s over five years since I had to administer a Jira workflow but it was hellish then and I suspect it’s not got much better since. Because there’s such complexity, there’s a big ramp up time and large learning curve; therefore, teams are not incentivised to change their process. Changing your process would be one of the key outcomes of an inspect and adapt cycle and a core fundamental of continuous improvement.

The final reason I’d advise people to steer clear of Jira? Because physical boards are awesome. A physical card wall is a totem for the team ; it’s an information radiator that anyone who’s passing by can look at and engage in a conversation around. Jira, meanwhile, hides that away behind a login screen – it actively discourages you from looking at work in progress.

Nothing creates a sense of connection with your work quite like a physical card wall . There’s a real sense of meaningful progress when you move cards around on a wall that you just don’t get by dragging them with a mouse. And there’s plenty of research to show that progress, no matter how small, is motivating for individuals and teams.

So why would you use Jira instead of a physical board? If you want a backup of the wall (what happens if someone defaces the cards or the building burns down) then take a photo every day. If you want interaction in a split-site team, have two card walls that are kept in sync by a team member on each end of the divide. If you want charts, draw them by hand – a big visible chart in the team area is much more valuable than a tiny one hidden on a dashboard.

I know some teams love Jira – I worked with one who were devastated that it had been taken away from them in favour of a (much larger, more bloated) agile lifecycle management tool. But I know just as many teams who’d much rather not use Jira or any electronic tool at all. All I’m asking is that you see the world beyond Jira – try not using any tool, try using a lighter weight tool and then go back to Jira if you really think you’re missing out on something.

10 thoughts on “Why all the Jira hate? I’ll tell you why

  1. In my current engagement I started with a bunch of teams that were waterfalling within sprints … and they had this big excuse of how their JIra process mandated them to work (with massively micromanaging stepped multi interim status subtasked based workflows … ahhhhhgggg). My immediate solution so that they would really understand the whole idea of Scrum and the teams’ behaviours and dynamics was: I got rid of Jira altogether. After a few sprints working out of the wall board. They then had the option to go back to a jira process reflective of their new way of working together, but they simply didn’t care about it anymore.

  2. I love Jira (much better than post-it notes stuck to my screen or trying to track change requirements spread across emails) but I certainly agree with the points you have made here, particularly about visibility, satisfaction, the feeling of progress, etc that Jira takes away.

  3. So many flaws in this post but I’ll try to stick to just a few. And while I do love JIRA, I love people more, so I never would use the tool as a crutch for poor behavior. Three main counterpoints to your post:

    – People thinking that just because they are using JIRA that means they are “agile” is not a problem with the tool. People are ultimately lazy and don’t want to do the hard work necessary to truly embrace agile methodologies — this is true. But don’t blame JIRA.
    – You haven’t used JIRA to develop workflows for five years, but complain that it still must be hard to use. Actually, Atlassian has done a bunch of work to help admins over the past few years and the tool is much easier to use now.
    – Yes, you don’t need a digital board and moving cards by hand is a wonderful feeling. But the fact is that so many teams are geographically dispersed that you need a single source of truth for your efforts that everyone can access. Colocation just isn’t as possible as most companies would like, and software helps connect those teams.

    JIRA is by no means a perfect tool, and you make some valid points about how it could be improved (especially how it calls everything an “issue”) but JIRA (or other tools) does many things right and the scorn just makes further conversations difficult.

    • Hi Dave,

      Thanks for commenting on my flawed post. Yes, it’s a rant, it’s not meant to be entirely balanced.

      You could substitute other tools in there for most of the points; Jira just happens to be thr most prevalent. However, I would argue that a lot of the marketing of Jira pushes it out of its original role as a bug tracker into being an ALM tool which it was never designed to be.

      I’m sure Atlassian has made it easier to use. I know that they’ve also invested huge amounts in making it faster. But it is still a very complex product with a steep learning curve. I know that from multiple conversations with people who use the tool regularly.

      For geographically dispersed teams, I agree that a tool is often needed but I would argue that you should pick the simplest tool that you can. And my personal opinion is that Jira doesn’t fall into that category.

      As I say in my final paragraph, I would always suggest that a team try not using a tool and then add a tool in to fill in any gaps they find. It’s much easier to add processes and tools to help in a particular area than to start with heavyweight tools or processes and then strip things out (loss aversion).

      I know lots of teams who are happy with Jira and that’s fine by me if they’ve chosen that. What I object to is a blanket mandate on using any tool or a mindless adoption of a tool without thought about what it’s meant to achieve.

  4. I agree that agile does not equal to applying jira. But seriously?

    “If you want a backup of the wall (what happens if someone defaces the cards or the building burns down) then take a photo every day. ”
    “If you want interaction in a split-site team, have two card walls that are kept in sync by a team member on each end of the divide.”
    “If you want charts, draw them by hand – a big visible chart in the team area is much more valuable than a tiny one hidden on a dashboard.”

    This really send us back to Stone Age.
    What you really need is just big TVs hung in your office rooms.

  5. Andy – you are not alone in your thoughts here – I have heard similar feedback from many the wonderful, diverse ecosystem of application development. However, you and readers of this post should consider the following in selecting any tools / designing processes to implement & execute agile in your development work:

    1) correct – installing a tracker (any) doesn’t make your processes or delivery magically agile; process design, training, etc need to be considered
    2) swim lanes (in boards), ‘issue’ types, and workflows in JIRA are all configurable; thus any issue with those points directly back to an admin’s config (but really the thought or lack thereof behind designing these); JIRA implementations fail because of bad configuration, and worse when laid on top of bad process design (compounding headaches for all)
    3) the cards / boards in JIRA contain the same schema / data as any other tool, and you can add custom fields, etc – I am not sold that JIRAs boards / cards are really different at all than others in other tools
    4) yes, JIRA is complex to configure, but that is learnable; end users simply need to learn the views, issue types, and workflows to be successful- they will never touch the configurations, which is where the real complexity lies
    5) there’s a lot missing here about what JIRA ​can do_ against other tools (what other tools don’t have): configurable security model, configurable notifications, custom fields, massive workflow customizations, a gigantic app store of sorts to extend out of the box, infinite programmatic extensibility capabilities, a slew of canned reports, ability to use query language (JQL) to access project data, cross project / program / portfolio management tools for professional services firms, time tracking, resource planning, and much, much more; you can call this bloat, or you can call this a powerful tool set (especially when you extend it with testing automation, repos, etc in tools like bamboo, bitbucket, etc) to manage everything you need from a PM or dev ops perspective

    Most importantly, there’s no ‘perfect solution’ out there for any tracking methodology and the tool set that supports it. The better teams out there acknowledge this, and they practice continuous improvement through ceremonies like retrospectives. What you have presented here is interesting, and it will likely draw many eyeballs and views on your site, but it is not a full picture of what teams need to consider implementing agile properly and how to select (and then configure) the right tool set to drive that forward.

  6. Great post and I’m feeling it one week into a project that is being driven by this tool. I also find it so busy and hats to find things, ask its labels, dropdowns, plugins ect. Totally gets in the way, I thinks it’s for the “doing agile” crew.

  7. The real problem with Jira to me (just going through onboarding to new project using Jira), is that it feels like it is developed by academics who try to over-develop an “agile tool” for business and process managers who don’t have a lot of experience with “real world” projects. Yes a tool does not make you “agile”.

    There is just too much to Jira, and basic features seem buried in the app. The “kanban” view does not expose basic story functions at the top level. Some basic task/story management requires so many clicks (for instance, changing the status of a story with subtasks), that is just seems overly complex. Also the rigidity of suggested workflows requires more customizations than seems necessary when compared to a tool like Pivotal.

    The whole philosophy of Jira seems tied to a “top down” academic understanding of management processes (trying to manage through graphs and analytics), rather than a “bottom up” style of real world “agile” project management. It’s really not that complicated, but Jira loves complexity it seems. (Also notification preferences can not be set with any granularity at the member account level.)

    Jira seems like an “excuse” for teams to justify unecessary complexity and workload at the management level. Just like academic bureaucrats like it. Apply the agile philosophy to Jira, and I don’t think it holds up, especially in the user interface.

    Would not be my first choice.

Leave a Reply

Your email address will not be published. Required fields are marked *