To wade in on the JIRA wars going on, I was once a JIRA consultant (among other things).
I ended up telling people I worked on business process design because once you see 100 different ways people are using a tool you learn most of the wrong ways to do it.
The primary issue with any task tracking or workflow tool is that the people implementing it have never learnt what is effective and what isn't. Worse, what is effective changes depending on what exact kind of task you are trying to track, in addition to the organisation and everything else.
I would typically start, regardless of what the particular thing I was brought in to help with was, with getting management/project leads/etc to agree to what outcomes they want from a tool like JIRA.
Companies have processes that get followed, and management need to provide direction and measure what's being done. Overwhelmingly there seems to be no good way of transferring information between these layers, of people doing work and other people trying to understand what that work is.
A good tool will make it easy for that information to flow.
The problem is that for the information to be useful it needs to be accurate and complete, you need people to actually use the tool. Every time you add a gate to a task (this person must accept this before it progresses, or this field has to be filled out) you add friction to the process and people disengage (often using a different tool altogether like excel or sticky notes).
At the same time, a well designed tool supports people doing their work. Prompts remind people what things need to be checked or completed at each step, and notifications can let you know when something needs doing.
As long as you can get people to agree to these concepts, you can start to design workflows and information to capture that will be useful for the people using it, and useful for the people trying to work out what is happening.
JIRA also takes a while to learn how to architect sustainably. If you create 20 copies of different screens it becomes a real chore to go in and change them down the track. If you do have a bit of foresight and experience, however, it's not hard to manage hundred of projects with different workflows and fields.
It has lots of warts and cruft that's built over time, and there isn't enough knowledge about how to use the good bits, so it gets a bad rap.
I know how to use it pretty well, and am normally in a position to change it when I need to, so don't run into the gripes that most people see.
The biggest positive however is not that it can do almost anything 'task-tracky' with a bit of effort - it's that it can do that and someone else maintains it. So many tools (internal and external) grow and grow and grow to try and cover things like assigning tasks and tracking workflow and sending emails, or run into a wall because VBA scripts in excel can only do so much. The ability to take almost any of those and add task tracking by simply integrating with JIRA is a huge selling point and has provided so much value to me over the years. That I can do the same for all parts of the business is the main reason it has spread so far in the enterprise world.
I remember the days that JIRA used to be snuck into small teams when no one was looking, and spread organically throughout the organisation after that because it was so useful.
> Every time you add a gate to a task (this person must accept this before it progresses …
This seems to be the standard failure mode. When a ticket is wrong, I try to fix it only to find I'm not allowed to, because the workflow presumes the actual state of the project today can't happen.
The solution of course it to just allow people to do what they want.
Every now and then it’s useful to everyone to stop some things from happening - it’s easier to have the gate than to not.
The fact that that exemption exists is what drives the pain most people have with systems like this.
My trick was to say “while we’re building this let’s just leave it as open as possible, we can lock it down once we’re sure the process works how we need it” - and then never lock it down (or just lock down the bits that people use to shoot themselves in the foot).
I ended up telling people I worked on business process design because once you see 100 different ways people are using a tool you learn most of the wrong ways to do it.
The primary issue with any task tracking or workflow tool is that the people implementing it have never learnt what is effective and what isn't. Worse, what is effective changes depending on what exact kind of task you are trying to track, in addition to the organisation and everything else.
I would typically start, regardless of what the particular thing I was brought in to help with was, with getting management/project leads/etc to agree to what outcomes they want from a tool like JIRA.
Companies have processes that get followed, and management need to provide direction and measure what's being done. Overwhelmingly there seems to be no good way of transferring information between these layers, of people doing work and other people trying to understand what that work is.
A good tool will make it easy for that information to flow.
The problem is that for the information to be useful it needs to be accurate and complete, you need people to actually use the tool. Every time you add a gate to a task (this person must accept this before it progresses, or this field has to be filled out) you add friction to the process and people disengage (often using a different tool altogether like excel or sticky notes).
At the same time, a well designed tool supports people doing their work. Prompts remind people what things need to be checked or completed at each step, and notifications can let you know when something needs doing.
As long as you can get people to agree to these concepts, you can start to design workflows and information to capture that will be useful for the people using it, and useful for the people trying to work out what is happening.
JIRA also takes a while to learn how to architect sustainably. If you create 20 copies of different screens it becomes a real chore to go in and change them down the track. If you do have a bit of foresight and experience, however, it's not hard to manage hundred of projects with different workflows and fields.
It has lots of warts and cruft that's built over time, and there isn't enough knowledge about how to use the good bits, so it gets a bad rap.
I know how to use it pretty well, and am normally in a position to change it when I need to, so don't run into the gripes that most people see.
The biggest positive however is not that it can do almost anything 'task-tracky' with a bit of effort - it's that it can do that and someone else maintains it. So many tools (internal and external) grow and grow and grow to try and cover things like assigning tasks and tracking workflow and sending emails, or run into a wall because VBA scripts in excel can only do so much. The ability to take almost any of those and add task tracking by simply integrating with JIRA is a huge selling point and has provided so much value to me over the years. That I can do the same for all parts of the business is the main reason it has spread so far in the enterprise world.
I remember the days that JIRA used to be snuck into small teams when no one was looking, and spread organically throughout the organisation after that because it was so useful.