[rando444]

I don't follow any of his arguments.

The author suggests that Jira is partially to blame for people who don't fully understand Agile software development. I would argue it's not the software that's the problem.

Bad practice in workflows? If you have a bad workflow, the software is not the issue.. and the author's argument that making workflows is 'difficult', just doesn't hold water with me.

His final argument to steer clear of Jira because physical paper is 'better' isn't even an argument against Jira, it's an argument against all organizational software.

I never knew there was jira hate before this posting, and only leaves me wondering 'Why all the Jira hate?'

[tapanjk]

Github/Gitlab (gh/gl) for source control is [almost] universal in enterprises, but it is quite confusing to me why these enterprises end up not using gh/gl issues for task management and tracking. Both of these now have well implemented project boards and these are way faster and more usable than traditional alternatives including Jira. For a developer, it is way easier and more effective to spend time creating and updating issues in gh/gl than using an entirely different solution. Open source projects have already demonstrated the effectiveness of gh/gl issues, but enterprises continue to rely on "enterprisey" solutions. I think this is mainly because the choice of project management tool is in the hands of developers in case of open source, but mostly with project/product managers in case of enterprises. As long as this remains the case, developers employed with enterprises will continue to have to live with tools that provide sub-optimal user experience.

Edit:

There is a good reason for project/product managers to prefer Jira and similar products. They want to be able to create dashboards with some very complex queries for reporting, and also features such as moving an Issue from one project to another, etc. In short, it provides management features that PMs rely on for reporting progress up the management chain.

[weitzj]

I would say that in the enterprise you would have for example a global strategy of the company for the next years. This would somehow map to your department and then somehow to your team. This means not everything needs to be sourcecode but probably Epics derives stories and derived tasks which might span across the company.