3 ms·

Yup, JIRA is a power-manager's wet dream. Whatever way one can think of for adding "things" to a task (and how to classify them, and how to keep track of them..

Yup, JIRA is a power-manager's wet dream. Whatever way one can think of for adding "things" to a task (and how to classify them, and how to keep track of them...), Atlassian has probably thought of it. For a developer who just wants to keep the tool at a distance and only log into it to move their shit across the scrum board and promptly log back out, they better hope their scrum overlords have looked upon them kindly.

cowmix 11y ago
Almost every time my company gets called in to do JIRA consulting the situation is this: Devs bring JIRA in.. JIRA gets popular.. things get out of control. It is almost NEVER brought in by management.
- alkonaut 11y ago
  In my opinion it's a range of management requests that give rise to the workflow, and devs hate managing workflows with email, notes ("When you are done implementing move the issue to the X column and send a message to the testers group that..."). So then devs bring in JIRA to do some automation. Now the tester person gets an email when the issue is moved to the testing phase. But once everything is in place, management will see the benefits, and the workflow will "evolve", especially if the teams grow. It's pretty natural.
- icehawk219 11y ago
  I used to be a dev who brought in JIRA because I like it out-of-the-box and it can grow with a team. But I always tell my manager to NOT TOUCH THE WORKFLOWS and to just let things grow organically as the needs of the team grow (or don't). And every time the moment they click around and see the workflow editor we ended up with some big, bloated, convoluted mess. I've been burned too many times, I no longer recommend JIRA to anyone.
daigoba66 11y ago
The trick is that Jira should be "owned" by the dev teams, not by management. Management shouldn't even have a login, except perhaps to submit bugs. The only exception is if Jira is used for project management type stuff - those projects can and should be isolated from dev projects.

cowmix 11y ago

Almost every time my company gets called in to do JIRA consulting the situation is this: Devs bring JIRA in.. JIRA gets popular.. things get out of control. It is almost NEVER brought in by management.

alkonaut 11y ago
In my opinion it's a range of management requests that give rise to the workflow, and devs hate managing workflows with email, notes ("When you are done implementing move the issue to the X column and send a message to the testers group that..."). So then devs bring in JIRA to do some automation. Now the tester person gets an email when the issue is moved to the testing phase. But once everything is in place, management will see the benefits, and the workflow will "evolve", especially if the teams grow. It's pretty natural.
icehawk219 11y ago
I used to be a dev who brought in JIRA because I like it out-of-the-box and it can grow with a team. But I always tell my manager to NOT TOUCH THE WORKFLOWS and to just let things grow organically as the needs of the team grow (or don't). And every time the moment they click around and see the workflow editor we ended up with some big, bloated, convoluted mess. I've been burned too many times, I no longer recommend JIRA to anyone.

daigoba66 11y ago

The trick is that Jira should be "owned" by the dev teams, not by management. Management shouldn't even have a login, except perhaps to submit bugs. The only exception is if Jira is used for project management type stuff - those projects can and should be isolated from dev projects.