5 ms·

I work in a fairly large S&P 500 company that uses JIRA to manage most of our software projects. While I do agree that the performance of JIRA can leave a bit t

by cebert 3y ago

I work in a fairly large S&P 500 company that uses JIRA to manage most of our software projects. While I do agree that the performance of JIRA can leave a bit to desire at times, I don’t feel the same animosity towards it as many seem to. Since we also use GitHub Enterprise, I’d personally prefer to use GitHub for issue management but I can live with JIRA. Perhaps I’m just fortunate to work under leaders who don’t force a lot of overburdening JIRA processes. At my work each team can setup their JIRA project and workflows, boards, etc. in a manner that makes most sense for them. Teams can use hours or story points, kanban or scrum. The focus is on delivering features and quality (in terms of customer reported open CRM issues not JIRA issue counts). I feel like management is pretty transparent on how they use JIRA and what their expectations are. My boss and their boss openly share with us what they look for in terms of team project health. I feel like anyone on my team could suggest a reasonable JIRA process change and it would be considered.

igetspam 3y ago
> I’d personally prefer to use GitHub for issue management but I can live with JIRA. No, you wouldn't. I promise. You'd spend months fucking around with GitHub Projects, hoping you could figure out how to unclusterfuck it and you'd miss Jira. It's not good enough. I didn't know how much I actually didn't hate Jira until I worked at a company that tried every other option. They all suck. Jira sucks less.
fatnoah 3y ago
> The focus is on delivering features and quality In my first month as VP at a growth stage startup, I asked everyone in Engineering why we used Jira. The responses all boiled down to what was basically a shrug. I followed up with what they felt we should use it for and the universal answer was just to be a scrum board, so I spent a bunch of time removing fields and nearly all workflow steps and rules enforcement except in cases where a particular team wanted them. This ruffled a few feathers of folks who loved making tools do all the work, but the improved QoL and happiness the team at made any objections moot. Similarly,I asked all the external stakeholders what they wanted out of the Engineering team, and the common answer was regular delivery of features and products. So now that's what we're optimizing our process around, and (not a surprise) that's been more of a "make the product team focus on fewer things", reduce architectural debt, and automate more things kind of effort. Now, estimation is still a big part of this, but it's used mostly for capacity planning and to gauge the effectiveness of efficiency related efforts.

by cebert 3y ago

igetspam 3y ago

> I’d personally prefer to use GitHub for issue management but I can live with JIRA. No, you wouldn't. I promise. You'd spend months fucking around with GitHub Projects, hoping you could figure out how to unclusterfuck it and you'd miss Jira. It's not good enough. I didn't know how much I actually didn't hate Jira until I worked at a company that tried every other option. They all suck. Jira sucks less.

fatnoah 3y ago

> The focus is on delivering features and quality In my first month as VP at a growth stage startup, I asked everyone in Engineering why we used Jira. The responses all boiled down to what was basically a shrug. I followed up with what they felt we should use it for and the universal answer was just to be a scrum board, so I spent a bunch of time removing fields and nearly all workflow steps and rules enforcement except in cases where a particular team wanted them. This ruffled a few feathers of folks who loved making tools do all the work, but the improved QoL and happiness the team at made any objections moot. Similarly,I asked all the external stakeholders what they wanted out of the Engineering team, and the common answer was regular delivery of features and products. So now that's what we're optimizing our process around, and (not a surprise) that's been more of a "make the product team focus on fewer things", reduce architectural debt, and automate more things kind of effort. Now, estimation is still a big part of this, but it's used mostly for capacity planning and to gauge the effectiveness of efficiency related efforts.