5 ms·

first step of any agile transformation is to get yourself neck deep into atlassian products. 2nd step is to setup complex JIRA workflows and reporting and use

first step of any agile transformation is to get yourself neck deep into atlassian products. 2nd step is to setup complex JIRA workflows and reporting and use it to break all agile principles. third step is for your devs to take none of this seriously and put fake data into JIRA which your middle managers never catch onto. then your engineers who actually want to get shit done leave and you're left only with people who put fake shit into JIRA.

justinjlynn 5y ago
This is so close to reality it really hurts - like a good The Onion article... excellent satire. Powerful tools are flexible enough to be used correctly by knowledgeable people and help people become knowledgeable. Badly designed tools are tools which don't help people become knowledgeable and don't prevent unknowledgeable people from harming themselves or others using them. Atlassian tools, like JIRA, are almost always powerful and flexible -- capable of great good in the hands of knowledgeable people. However, they are not well designed tools, and so - the vast majority of JIRA installations and setups are just as broken as the orgs which install them and JIRA offers absolutely zero assistance or resistance to that brokenness.
- denimnerd42 5y ago
  Right, it turns into a political game instead of a powerful and useful tool. We have no control over how we use JIRA. It's all prescribed by someone and we don't even know who or how to reach out to them. Even the middle managers don't know how JIRA is being prescribed. They go one step worse and make Tableau dashboards from JIRA to track their own metrics that are so bad it's just... like The Office. We play the game though every day and get great feedback. This feedback is never from our customers (internal) though. Although they give us great feedback as part of the game too. Our actual delivery is very inefficient and slow though. The hierarchical structure of the org is such that feedback never makes it up the chain because that's highly discouraged. So they just keep wasting money.
  - justinjlynn 5y ago
    Yes. Long feedback loops and perverse or misaligned incentives == PAIN. Tools like JIRA do absolutely nothing to discourage nonsense like that - and, in fact, provide features designed to support workflows which require them.
    - denimnerd42 5y ago
      Yeah. it never makes sense to make any noise about it either because the people you can reach either don't understand the problem or don't have the power to fix it. It only makes the person making noise look bad.
      - justinjlynn 5y ago
        sigh Yeah. The bad news is that I've never heard of a workplace that's managed to change that culture once it's set in. The good news is that there are plenty of places to work which don't have that nonsense - which you can work in, if you can find them; which, to be fair, is pretty difficult. That said, it's worth the effort. That's one of the questions I ask potential employers - "Say I'd like to make a small change to the workflow, in order to meet an oversight requirement - for example, on a project I'm engineering - how would I go about doing so using your work tracking system? How many people would I need approval from to do so? Let's assume the effect is internal to my project and would require no other team to change how they work. Is that possible?" The answer usually says a lot more about the prospective employer than any technical questions about their code-bases do - and those are generally easy to suss out with a quick inspection, and SCM log perusal, anyway.
  - eropple 5y ago
    This is super common, and it's one reason why I have always volunteered (even though it sucks) to be the Jira Person. I'm experienced with it and have a good handle on how not to make it a big giant workflow mess, and I can then make sure that, by not being shy about who's running it and managing it, that feedback goes somewhere actionable.
- danielfranz 5y ago
  Imho the power and customisability of Jira is great. The problem is just its UI and performance. There are solutions to that though. You can always JXL your Jira (https://jxl.app https://jxl.app).
SkyPuncher 5y ago
I think too many places try to treat their tickets system as a source of truth, rather than simply a work management system. * A task with a title that can be understood in context (by the implementer/stakeholder) is sufficient. * Pointing/effort estimate is even better. Ideally, everything should have points because it helps the team manage workflow and set expectations. * A description is nice, but often completely unnecessary. In fact, I'd prefer no description to a stale description. From there, individual teams/developers should choose whatever tools they prefer for actually implementing a feature.
- handrous 5y ago
  Trying to use one tool as both a reporting-to-management system and a communication medium for the people actually doing the work, is a great way to make it fucking useless for both purposes. And yet, that's the norm with ticketing systems.
  - phkahler 5y ago
    Don't forget trying to use it for "productivity metrics".
  - jacobr1 5y ago
    Also, even for the people doing the work overloading communications to include not just tracking/assigning work, but also describing the requirements or details
jmathai 5y ago
This is gold. I’m one of those engineers who left. But I didn’t leave before creating this tool for others who were staying behind. It automatically reassigns your JIRA tickets to someone else. Very handy right before stand ups and scrum of scrums where they look at who has the most open tickets. The goodbye email where I linked to this was the highlight of my career. https://github.com/jmathai/all-hands-on-deck https://github.com/jmathai/all-hands-on-deck
- deleted 5y ago
  [deleted]
- krysp 5y ago
  This is fantastic. Probably works best in a massive organisation; did that goodbye email burn any bridges?

justinjlynn 5y ago

This is so close to reality it really hurts - like a good The Onion article... excellent satire. Powerful tools are flexible enough to be used correctly by knowledgeable people and help people become knowledgeable. Badly designed tools are tools which don't help people become knowledgeable and don't prevent unknowledgeable people from harming themselves or others using them. Atlassian tools, like JIRA, are almost always powerful and flexible -- capable of great good in the hands of knowledgeable people. However, they are not well designed tools, and so - the vast majority of JIRA installations and setups are just as broken as the orgs which install them and JIRA offers absolutely zero assistance or resistance to that brokenness.

denimnerd42 5y ago
Right, it turns into a political game instead of a powerful and useful tool. We have no control over how we use JIRA. It's all prescribed by someone and we don't even know who or how to reach out to them. Even the middle managers don't know how JIRA is being prescribed. They go one step worse and make Tableau dashboards from JIRA to track their own metrics that are so bad it's just... like The Office. We play the game though every day and get great feedback. This feedback is never from our customers (internal) though. Although they give us great feedback as part of the game too. Our actual delivery is very inefficient and slow though. The hierarchical structure of the org is such that feedback never makes it up the chain because that's highly discouraged. So they just keep wasting money.
- justinjlynn 5y ago
  Yes. Long feedback loops and perverse or misaligned incentives == PAIN. Tools like JIRA do absolutely nothing to discourage nonsense like that - and, in fact, provide features designed to support workflows which require them.
  - denimnerd42 5y ago
    Yeah. it never makes sense to make any noise about it either because the people you can reach either don't understand the problem or don't have the power to fix it. It only makes the person making noise look bad.
    - justinjlynn 5y ago
      sigh Yeah. The bad news is that I've never heard of a workplace that's managed to change that culture once it's set in. The good news is that there are plenty of places to work which don't have that nonsense - which you can work in, if you can find them; which, to be fair, is pretty difficult. That said, it's worth the effort. That's one of the questions I ask potential employers - "Say I'd like to make a small change to the workflow, in order to meet an oversight requirement - for example, on a project I'm engineering - how would I go about doing so using your work tracking system? How many people would I need approval from to do so? Let's assume the effect is internal to my project and would require no other team to change how they work. Is that possible?" The answer usually says a lot more about the prospective employer than any technical questions about their code-bases do - and those are generally easy to suss out with a quick inspection, and SCM log perusal, anyway.
- eropple 5y ago
  This is super common, and it's one reason why I have always volunteered (even though it sucks) to be the Jira Person. I'm experienced with it and have a good handle on how not to make it a big giant workflow mess, and I can then make sure that, by not being shy about who's running it and managing it, that feedback goes somewhere actionable.
danielfranz 5y ago
Imho the power and customisability of Jira is great. The problem is just its UI and performance. There are solutions to that though. You can always JXL your Jira (https://jxl.app https://jxl.app).

SkyPuncher 5y ago

I think too many places try to treat their tickets system as a source of truth, rather than simply a work management system. * A task with a title that can be understood in context (by the implementer/stakeholder) is sufficient. * Pointing/effort estimate is even better. Ideally, everything should have points because it helps the team manage workflow and set expectations. * A description is nice, but often completely unnecessary. In fact, I'd prefer no description to a stale description. From there, individual teams/developers should choose whatever tools they prefer for actually implementing a feature.

handrous 5y ago
Trying to use one tool as both a reporting-to-management system and a communication medium for the people actually doing the work, is a great way to make it fucking useless for both purposes. And yet, that's the norm with ticketing systems.
- phkahler 5y ago
  Don't forget trying to use it for "productivity metrics".
- jacobr1 5y ago
  Also, even for the people doing the work overloading communications to include not just tracking/assigning work, but also describing the requirements or details

jmathai 5y ago

This is gold. I’m one of those engineers who left. But I didn’t leave before creating this tool for others who were staying behind. It automatically reassigns your JIRA tickets to someone else. Very handy right before stand ups and scrum of scrums where they look at who has the most open tickets. The goodbye email where I linked to this was the highlight of my career. https://github.com/jmathai/all-hands-on-deck https://github.com/jmathai/all-hands-on-deck

deleted 5y ago
[deleted]
krysp 5y ago
This is fantastic. Probably works best in a massive organisation; did that goodbye email burn any bridges?