5 ms·

JIRA is a framework for making assembly lines out of knowledge workers. When you're a middle manager at a decent sized company, a major problem you face is that

JIRA is a framework for making assembly lines out of knowledge workers. When you're a middle manager at a decent sized company, a major problem you face is that the mass of knowledge workers beneath you are opaque: you have no way of knowing whether they're working or not. Another problem you face is that they're uppity: people who went to college and got used to managing their own time now have all kinds of idiosyncratic ideas about how to manage their own time and arrange their own working lives. Since you are a middle manager you despise local differences. Since you are a manager you're pretty sure that only you and your lieutenants can be trusted with this kind of decision making power. Adopting JIRA is a powerful level to put people back in their place as work item churning machines. Constraints such as only certain people can create or assign tickets, only certain people can mark them completed, only certain states are valid transitions from other states, etc. implement a level of domination over white-collar workforces that managers would be otherwise uncomfortable asserting face to face. Other ticketing systems do not work nearly as well for this purpose because they are designed mainly as external brains or communication platforms for workers, and they assume a level of worker autonomy in moving tasks through their lifecycle. In Trello you cannot make it so that a PM has to sign off before a card is moved to the in-progress column, or that only in-progress cards can have code reviews associated with them. JIRA eats these kinds of requirements for breakfast. EDIT: This is not to say you can't use JIRA in a workflow-neutral way, or that everyone uses it for this reason, but I would submit that it's JIRA's differentiated advantage.

Rimbo 5y ago
Oh, nonsense. People buy Atlassisn because the licensing is cheap, not because it's particularly good at what it does or designed with any particular workflow in mind.
- ofrzeta 5y ago
  I don't see how it is cheap. Standard may be cheap but then you are missing a lot of features that are announced on the product pages with a small footnote saying "only in premium".
- Viliam1234 5y ago
  Cheaper than whatever is the open-source alternative?
  - chaosite 5y ago
    Sure, if you host it yourself you have to pay someone to admin it (usually significantly more expensive than a license), and if you use a hosted solution you have to pay the host.
  - ivan_gammel 5y ago
    Free software has zero acquisition cost, but non-zero TCO, which can measure in millions USD (recurring salary of dedicated IT team), depending on the size of organization and complexity of the setup. You will need to maintain on-premise infrastructure, automate backups and recovery, automate security, automate updates (including testing and rollbacks) etc etc, basically doing all the jobs of the people responsible for the infrastructure at the SaaS provider, but at much smaller scale and not achieving the same efficiency. You will have to do those jobs considerably better to justify the costs.
    - mistrial9 5y ago
      in thirty years of experience, I see this talking point straight from Microsoft anti-Open Source days.. > Free software has zero acquisition cost, but non-zero TCO, which can measure in millions USD Often a primary driver is exactly the opposite -- for-profit companies are accustomed to paying money for a good or service, with a billing pattern and legal obligations. The company financial deciders do not want a setup that does not have a billing pattern and clear legal obligations. Meanwhile, Open Source Software went from niche to mission-critical in the 2000s via the Internet. For-profit companies (and their publicists) scrambled to explain it, and came up with that exact line repeated again today. I do not blame any person for saying it, it was in print in some reliable place. It does not capture the reality in 2022 IMO.
      - ivan_gammel 5y ago
        To be honest, I do not understand your comment. > The company financial deciders do not want a setup that does not have a billing pattern and clear legal obligations. I haven’t ever met a CTO or CIO, who would make budget decisions like that, neither I do it this way myself. The reality in 2022 is the same as it was in 2012 or in 2002: when you choose a solution, you consider all long term costs. In 2022 TCO for the server software includes everything that I mentioned in my comment and more. There’s a lot of use cases for OSS in corporate environment, for sure, but not every OSS solution is cheap or even affordable. Running on-premise open source collaboration tool is certainly not cheap if you do it right.
_dark_matter_ 5y ago
I feel you here, but I've been at multiple companies that used JIRA and never once had any of those requirements. I've also never seen it come up when deciding which ticketing system to use. Teams have always been free to move tickets at-will.
- KptMarchewa 5y ago
  One very large video game studio has tons of automation for Jira. Imagine someone deciding to add new weapon. The automation creates 100s of tasks for concept artists, 3d artists, animators, sound artists, software developers with complex dependencies better those. Most importantly, automation creates multiple QA steps for each element of completed work. The same exists for levels, enemies, quests and tons of other elements. I would not be surprised if a lot of studios had similar workflows.
  - BlargMcLarg 5y ago
    See, that is great. Automate what can logically be deduced from the information available and set up templates to provide that information. For developers, it should be automated enough you shouldn't have to write the same info twice, once in commit messages/merges/branch names, once in the ticket itself. If the workflow is so streamlined, all that information can be deduced and the ticket can be advanced automatically. Most information is available and documented for other parties. However, that's just not what most people go through in companies using JIRA. Worse, they have to toggle between pages multiple times, each taking at least a few decent seconds to reload. I'd like to give JIRA the benefit of the doubt here, but it sounds like the tool is just very easy to misconfigure and abuse.
    - robertlagrant 5y ago
      This is pretty easy with Jira. There's a GitHub plugin which links PRs and commits to a ticket, and a GitHub plugin that links ticket numbers back to Jira tickets. And you generally do them both at a lower level than tickets, certainly commits, so you don't want to have too much automation between them as that starts adding constraints.
codycraven 5y ago
It sounds like you've been hurt by the some terrible management practices, I'm truly sorry that some managers think their job is to control their subordinates. However, regarding ticketing systems, in team environments, it is very effective and helpful to have a system that manages the data about the work that has been completed, is being worked, and is planned to be worked on . Part of that system might be defining restrictive workflows for some teams, not for control, but to ensure the agreed upon process is followed for quality or consistency. One of the many problems Jira has is that if you don't have a Jira admin on your team, it's impossible to build an effective and efficient workflow for your team. Coupled with Jira making many things global by default (it takes a lot of care to make a change that only affects specific Jira projects) most configurations end up being a pile of garbage automatically inherited from changes an admin(that is not part of the team) made when intending to change something for another specific team.
- sjtindell 5y ago
  Agreed. This is a problem of scale in my opinion. When we have 10 engineers, it is easy to check in with everyone and know what they are working on and get a status update. When we have 500 engineers, making sure all their tasks are aligning (organizations are one big race condition) is not just hard but impossible without some sort of tracking system. We all want to grow big. To do so, your processes need to change as you add more people. The exceptions (Valve, Netflix, etc.) that can handle being flat or semi-flat are very unique.
  - biomcgary 5y ago
    Are they unique because their problem domain allows it or because the leadership is uniquely ideologically driven (and competent) to implement efficient, flat systems?
    - sjtindell 5y ago
      I think it’s mostly the people. They are die hard about their culture. At most of my workplaces, culture is generic and the company would be willing to set whatever culture rules seemed to work.
theptip 5y ago
I think you've got part of the answer here, but are selling it short. Jira is the most complex task-processing rule engine that is also easy enough for a small team to operate, and also has the broadest set of integrated tools of any offering. You can use Jira as a simple Scrum board, a Kanban board, or you can build enforced-process monstrosities. You can build customer-support / internal-helpdesk workflows, or even model internal work-item-oriented business processes, etc. Now, as you point out, just because you can doesn't mean you should, and many orgs fall into the trap of making issue workflows overly-restrictive. But most companies (I believe) choose Jira before they choose those hairy task workflows. Startups with zero process use Jira. Also, you can integrate it all together to give good-enough dashboards/roadmaps, good-enough (for some, not me) docs integrations with Confluence, Git integration with Bitbucket etc. -- while there are big issues with these systems, I think it would be myopic to ignore the real benefits of working in one integrated stack where every design doc you write has dynamically-updated labels and auto-complete for each issue you type in. For context, I use Jira for tasks and don't love it, found Confluence to be really annoying and so I don't use it, and prefer Gitlab to Bitbucket, but I think you have to recognize these unique selling points. If all Jira had to offer was the rule engine it would not be as widely used.
- pid-1 5y ago
  Yeah my team uses Jira to keep track of what we are doing and what we need to do. Each member can actually organize their sprint and create tasks. Point assignment is not a big deal, it's just there so we avoid promising more than we can chew. I've found Jira really pleasant to use for lightweight processes.
TheRealDunkirk 5y ago
Even worse, companies with the resources to buy JIRA will probably hire consultants to set it up, and you wind up with a system 1) bought by people who don't understand how programmers work, 2) configured by people who don't know how your company works. So end users usually wind up with a terrible system that continually generates complaints (along MANY axes), and the people responsible for foisting it on them think they're just being difficult.
mikepurvis 5y ago
So I would say that this assessment is on the whole, kind of cynical, however I suppose I have the interesting position of being in an organization where I feel like I actually see both JIRAs. One JIRA is the project that's used for development of the core product, where there are no constraints— anyone can add a comment, create links, change assignee, add new tags, push the tickets through whatever state transitions they want, and so on. It works, though it is a little chaotic sometimes as subgroups of people have different preferences for how things should go (eg, for tickets requiring test team validation, should the ticket assignee remain as the person who did the original work so it's clear who has more to do if it fails validation, or should the assignee change to the test team person, so that it's clear that that's the next person who has it as an action item?) The second JIRA is the IT team's internal support project, which is completely locked down— no one except them can close tickets or move them around, or even edit the contents, closed tickets can't be commented on any more, and so on. This is the one that gives me the vibes you are talking about. Every time I have to interact with it, I loathe it because every inch of it is transparently a funnel, railroading me along a path toward one of either DONE or WONTFIX. This is absolutely efficient, in the sense of meeting the goal of closing all the tickets, but I feel it introduces friction for the larger business goal of actually helping people resolve their problems. To the point where eventually most of the IT support activity moved away from the JIRA project to an informal Slack channel, which is way more accessible, but worse in basically every other way: it's harder to effectively search, impossible to properly link, bad for async, bad for dealing with more than one thing at once, etc.

Rimbo 5y ago

Oh, nonsense. People buy Atlassisn because the licensing is cheap, not because it's particularly good at what it does or designed with any particular workflow in mind.

ofrzeta 5y ago
I don't see how it is cheap. Standard may be cheap but then you are missing a lot of features that are announced on the product pages with a small footnote saying "only in premium".
Viliam1234 5y ago
Cheaper than whatever is the open-source alternative?
- chaosite 5y ago
  Sure, if you host it yourself you have to pay someone to admin it (usually significantly more expensive than a license), and if you use a hosted solution you have to pay the host.
- ivan_gammel 5y ago
  Free software has zero acquisition cost, but non-zero TCO, which can measure in millions USD (recurring salary of dedicated IT team), depending on the size of organization and complexity of the setup. You will need to maintain on-premise infrastructure, automate backups and recovery, automate security, automate updates (including testing and rollbacks) etc etc, basically doing all the jobs of the people responsible for the infrastructure at the SaaS provider, but at much smaller scale and not achieving the same efficiency. You will have to do those jobs considerably better to justify the costs.
  - mistrial9 5y ago
    in thirty years of experience, I see this talking point straight from Microsoft anti-Open Source days.. > Free software has zero acquisition cost, but non-zero TCO, which can measure in millions USD Often a primary driver is exactly the opposite -- for-profit companies are accustomed to paying money for a good or service, with a billing pattern and legal obligations. The company financial deciders do not want a setup that does not have a billing pattern and clear legal obligations. Meanwhile, Open Source Software went from niche to mission-critical in the 2000s via the Internet. For-profit companies (and their publicists) scrambled to explain it, and came up with that exact line repeated again today. I do not blame any person for saying it, it was in print in some reliable place. It does not capture the reality in 2022 IMO.
    - ivan_gammel 5y ago
      To be honest, I do not understand your comment. > The company financial deciders do not want a setup that does not have a billing pattern and clear legal obligations. I haven’t ever met a CTO or CIO, who would make budget decisions like that, neither I do it this way myself. The reality in 2022 is the same as it was in 2012 or in 2002: when you choose a solution, you consider all long term costs. In 2022 TCO for the server software includes everything that I mentioned in my comment and more. There’s a lot of use cases for OSS in corporate environment, for sure, but not every OSS solution is cheap or even affordable. Running on-premise open source collaboration tool is certainly not cheap if you do it right.

_dark_matter_ 5y ago

I feel you here, but I've been at multiple companies that used JIRA and never once had any of those requirements. I've also never seen it come up when deciding which ticketing system to use. Teams have always been free to move tickets at-will.

KptMarchewa 5y ago
One very large video game studio has tons of automation for Jira. Imagine someone deciding to add new weapon. The automation creates 100s of tasks for concept artists, 3d artists, animators, sound artists, software developers with complex dependencies better those. Most importantly, automation creates multiple QA steps for each element of completed work. The same exists for levels, enemies, quests and tons of other elements. I would not be surprised if a lot of studios had similar workflows.
- BlargMcLarg 5y ago
  See, that is great. Automate what can logically be deduced from the information available and set up templates to provide that information. For developers, it should be automated enough you shouldn't have to write the same info twice, once in commit messages/merges/branch names, once in the ticket itself. If the workflow is so streamlined, all that information can be deduced and the ticket can be advanced automatically. Most information is available and documented for other parties. However, that's just not what most people go through in companies using JIRA. Worse, they have to toggle between pages multiple times, each taking at least a few decent seconds to reload. I'd like to give JIRA the benefit of the doubt here, but it sounds like the tool is just very easy to misconfigure and abuse.
  - robertlagrant 5y ago
    This is pretty easy with Jira. There's a GitHub plugin which links PRs and commits to a ticket, and a GitHub plugin that links ticket numbers back to Jira tickets. And you generally do them both at a lower level than tickets, certainly commits, so you don't want to have too much automation between them as that starts adding constraints.

codycraven 5y ago

It sounds like you've been hurt by the some terrible management practices, I'm truly sorry that some managers think their job is to control their subordinates. However, regarding ticketing systems, in team environments, it is very effective and helpful to have a system that manages the data about the work that has been completed, is being worked, and is planned to be worked on . Part of that system might be defining restrictive workflows for some teams, not for control, but to ensure the agreed upon process is followed for quality or consistency. One of the many problems Jira has is that if you don't have a Jira admin on your team, it's impossible to build an effective and efficient workflow for your team. Coupled with Jira making many things global by default (it takes a lot of care to make a change that only affects specific Jira projects) most configurations end up being a pile of garbage automatically inherited from changes an admin(that is not part of the team) made when intending to change something for another specific team.

sjtindell 5y ago
Agreed. This is a problem of scale in my opinion. When we have 10 engineers, it is easy to check in with everyone and know what they are working on and get a status update. When we have 500 engineers, making sure all their tasks are aligning (organizations are one big race condition) is not just hard but impossible without some sort of tracking system. We all want to grow big. To do so, your processes need to change as you add more people. The exceptions (Valve, Netflix, etc.) that can handle being flat or semi-flat are very unique.
- biomcgary 5y ago
  Are they unique because their problem domain allows it or because the leadership is uniquely ideologically driven (and competent) to implement efficient, flat systems?
  - sjtindell 5y ago
    I think it’s mostly the people. They are die hard about their culture. At most of my workplaces, culture is generic and the company would be willing to set whatever culture rules seemed to work.

theptip 5y ago

I think you've got part of the answer here, but are selling it short. Jira is the most complex task-processing rule engine that is also easy enough for a small team to operate, and also has the broadest set of integrated tools of any offering. You can use Jira as a simple Scrum board, a Kanban board, or you can build enforced-process monstrosities. You can build customer-support / internal-helpdesk workflows, or even model internal work-item-oriented business processes, etc. Now, as you point out, just because you can doesn't mean you should, and many orgs fall into the trap of making issue workflows overly-restrictive. But most companies (I believe) choose Jira before they choose those hairy task workflows. Startups with zero process use Jira. Also, you can integrate it all together to give good-enough dashboards/roadmaps, good-enough (for some, not me) docs integrations with Confluence, Git integration with Bitbucket etc. -- while there are big issues with these systems, I think it would be myopic to ignore the real benefits of working in one integrated stack where every design doc you write has dynamically-updated labels and auto-complete for each issue you type in. For context, I use Jira for tasks and don't love it, found Confluence to be really annoying and so I don't use it, and prefer Gitlab to Bitbucket, but I think you have to recognize these unique selling points. If all Jira had to offer was the rule engine it would not be as widely used.

pid-1 5y ago
Yeah my team uses Jira to keep track of what we are doing and what we need to do. Each member can actually organize their sprint and create tasks. Point assignment is not a big deal, it's just there so we avoid promising more than we can chew. I've found Jira really pleasant to use for lightweight processes.

TheRealDunkirk 5y ago

Even worse, companies with the resources to buy JIRA will probably hire consultants to set it up, and you wind up with a system 1) bought by people who don't understand how programmers work, 2) configured by people who don't know how your company works. So end users usually wind up with a terrible system that continually generates complaints (along MANY axes), and the people responsible for foisting it on them think they're just being difficult.

mikepurvis 5y ago

So I would say that this assessment is on the whole, kind of cynical, however I suppose I have the interesting position of being in an organization where I feel like I actually see both JIRAs. One JIRA is the project that's used for development of the core product, where there are no constraints— anyone can add a comment, create links, change assignee, add new tags, push the tickets through whatever state transitions they want, and so on. It works, though it is a little chaotic sometimes as subgroups of people have different preferences for how things should go (eg, for tickets requiring test team validation, should the ticket assignee remain as the person who did the original work so it's clear who has more to do if it fails validation, or should the assignee change to the test team person, so that it's clear that that's the next person who has it as an action item?) The second JIRA is the IT team's internal support project, which is completely locked down— no one except them can close tickets or move them around, or even edit the contents, closed tickets can't be commented on any more, and so on. This is the one that gives me the vibes you are talking about. Every time I have to interact with it, I loathe it because every inch of it is transparently a funnel, railroading me along a path toward one of either DONE or WONTFIX. This is absolutely efficient, in the sense of meeting the goal of closing all the tickets, but I feel it introduces friction for the larger business goal of actually helping people resolve their problems. To the point where eventually most of the IT support activity moved away from the JIRA project to an informal Slack channel, which is way more accessible, but worse in basically every other way: it's harder to effectively search, impossible to properly link, bad for async, bad for dealing with more than one thing at once, etc.