1–10 of 13 posts
I'm primarily thinking from the perspective of a software engineer (code contributions as well as organisation/planning) but other use cases would be interesting to hear about as well.
Recently I've been thinking of using it as a workflow automation tool. Instead of building one, we'd file a series of Jira tickets and would gradually automate each type of ticket while leaving the rest to humans. As we automate, Jira would be the single source of truth and agents would look for tickets for them and run the activities for those, marking their state accordingly.
The problem with JIRA is that all the integrations are awfully slow and happen client-side, so you basically load a page and can't find something you expect to see — until it loads 20s later.
Expanding on what @necovek said:
In a big company we used it, and while everything was "agile", there were very rigid processes in place (for a good reason). Those processes were properly translated and implemented into Jira. Development support teams wrote plugins to connect Jira with in-house systems and have proper synchronization with customer facing bug tracking systems, log monitoring and the like. We religiously logged time on stories, moved them accordingly, checked tasks "to review" before taking another task, and velocity and other stats were meaningful. It was still heavy for what it did, but overall helpful and I was glad to use it.
In another big company we used it, everything was "agile" too, but here it meant every team did whatever they wanted. Each SM had that role for 3-4 teams, meaning every board worked differently but sometimes close to one lowest common denominator among certain teams. Different patterns, meanings of columns, nobody logged anything, stuff had to be copy-pasted by hand to keep track of information on external systems. Velocity accuracy was all over the place, nothing meant much, except for the location of the tickets in the columns and the content inside. For which, obviously, you don't need something as heavy and slow as Jira; Jira is picked anyway because you have the chance to make it evolve into the first example. But if you don't allocate resources for that, Jira ain't going to do the job for you.
Sure, building the forms and the workflow is an annoying experience. If Jira admin hasn't set up a good separation of templates, things get mixed up and cluttered (for project admin tasks). And it feels like you're working for the system instead of it working for you (again, when building your flows).
Still, once you get used to Jira's way of putting things together, building what you want becomes "not so bad". And you can have pretty much whatever process you want in place.
I think devs dislike it because it's riddled with layers upon layers of abstractions targeting enterprise deployments. Meaning if you want something quick and simple, it's probably the wrong tool.
But at the end of the day, it's about the process you build and making sure the tools serve it (mostly on the daily work level rather than admin). Jira let me refine the process and didn't get in the way of others on the team. Frankly, we liked it.
Sure, you might argue that merely having the possibility of making processes complex is what makes them complex, but I think that's making the argument too easy on yourself.
Further these tools - like most huge and complex web apps, are slow, clunky, and buggy. And that obviously deserves criticism. But usually the biggest critcism of Jira is based on that it represents the whole concept of bureaucratic work of various states, transitions, bookeeping and reporting, which to us devs steals time from actual work. It's the scrum feature factory monitoring system.
But having been in such processes without the Jira and ADO type of tooling (e.g. having to message 3 different people and use 3 different home built tracking pages and 3 different emails in order to push a bug through the system), I can tell you having the tooling beats not having it.
At this point, doing everyone on GitHub itself is a very viable strategy to me, but I know that will never fly with people who obsess over story points and time estimates.
Jira is fine to me (as a SWE), but it's way too complex for untrained managers/PO/SM to use properly (read: to make it more useful than a simple kanban board). Expanding on what @necovek said: In a big company we used it, and while everything was "agile", there were very rigid processes in place (for a good reason). Those processes were properly translated and implemented into Jira. Development support teams wrote pl…
Interesting, do you think that Jira _requires_ that level of integration to be useful or could a simpler (e.g. less plugin development, synchronization with other systems e.t.c.) also be successful?