3 ms·

If a company is trying to use JIRA for more than state communication they are doing it wrong IMO. Planning goes into calendars, ephemeral stuff goes into chats

If a company is trying to use JIRA for more than state communication they are doing it wrong IMO. Planning goes into calendars, ephemeral stuff goes into chats and calls, and code and code-level issues goes into repositories. I have seen plenty of attempts to make a product like JIRA the 'interface' between some management person and 'the subordinates' and it never works, simply because trying to place an 'interface' there in itself doesn't work.

ryanbrunner 4y ago
I think what other tools miss that JIRA did well is giving engineering managers tools to communicate with upper management. You're right that actually attempting to use JIRA as the medium of communication with people outside the product org is hopelessly, fatally flawed, but being able to visualize an issue like an unmanageable backlog, or team productivity, or quality issues is invaluable, and a lot of simple tools throw the baby out with the bathwater by completely failing to give any tools to analyze how your team is doing. If it's configured properly, JIRA can be a fairly effective tool that mostly stays out of the way of developers but can help team leads and managers communicate things about the team.
- oneplane 4y ago
  That is indeed what happens with the simpler JIRA clones. On top of that, usually the org has no idea what is going on, who is working on what or what is still waiting to be looked at by anyone. Normally those issues would be handled with a simple 5 minute meeting (DSU or some variant thereof) where everyone shares their current state, and then a few times per month some form of "where are we and where are we going" type of planning. (Be it a sprint planning or something like it) Combining that with a state tracker seems like a fairly obvious thing to do, and having the tools to then report on that over time (graphs can be a helpful visualisation that simple tools usually lack) gives everyone some context as to how healthy the team is. But even that last bit, the concept of periodically having a bit of a check up to see how things are going is often lacking in "we can do it better and simpler" types of setups. In then end, it gets reduced back to the manager walking around with a whip shouting "work harder!" instead of teams having some autonomy and figuring their own state out themselves.
colechristensen 4y ago
>If a company is trying to use JIRA for more than state communication they are doing it wrong IMO. This is why tools that don't allow this kind of doing-it-wrong are significantly superior to Jira.
- oneplane 4y ago
  That's a nice theory, but in practise people have been mailing to Slack, using meetings to read emails and using JIRA to track Git commits. Tools are just slaves to reality, not the other way around. If a legacy top-down organisation wants you do to a certain thing a certain way, and you have no recourse but to do as you're told, that's your organisation's fault and nothing else. You can either gain a position where you can make changes, or leave the company. Complaining about a tool that has no influence over your work process really doesn't change anything.
  - lmm 4y ago
    > Tools are just slaves to reality, not the other way around. If a legacy top-down organisation wants you do to a certain thing a certain way, and you have no recourse but to do as you're told, that's your organisation's fault and nothing else. You can either gain a position where you can make changes, or leave the company. That's naive; tools influence the way they're used. When a tool defaults to having manager accounts that can change how things get done and developer accounts that can't, it nudges the organisation in that direction.

ryanbrunner 4y ago

I think what other tools miss that JIRA did well is giving engineering managers tools to communicate with upper management. You're right that actually attempting to use JIRA as the medium of communication with people outside the product org is hopelessly, fatally flawed, but being able to visualize an issue like an unmanageable backlog, or team productivity, or quality issues is invaluable, and a lot of simple tools throw the baby out with the bathwater by completely failing to give any tools to analyze how your team is doing. If it's configured properly, JIRA can be a fairly effective tool that mostly stays out of the way of developers but can help team leads and managers communicate things about the team.

oneplane 4y ago
That is indeed what happens with the simpler JIRA clones. On top of that, usually the org has no idea what is going on, who is working on what or what is still waiting to be looked at by anyone. Normally those issues would be handled with a simple 5 minute meeting (DSU or some variant thereof) where everyone shares their current state, and then a few times per month some form of "where are we and where are we going" type of planning. (Be it a sprint planning or something like it) Combining that with a state tracker seems like a fairly obvious thing to do, and having the tools to then report on that over time (graphs can be a helpful visualisation that simple tools usually lack) gives everyone some context as to how healthy the team is. But even that last bit, the concept of periodically having a bit of a check up to see how things are going is often lacking in "we can do it better and simpler" types of setups. In then end, it gets reduced back to the manager walking around with a whip shouting "work harder!" instead of teams having some autonomy and figuring their own state out themselves.

colechristensen 4y ago

>If a company is trying to use JIRA for more than state communication they are doing it wrong IMO. This is why tools that don't allow this kind of doing-it-wrong are significantly superior to Jira.

oneplane 4y ago
That's a nice theory, but in practise people have been mailing to Slack, using meetings to read emails and using JIRA to track Git commits. Tools are just slaves to reality, not the other way around. If a legacy top-down organisation wants you do to a certain thing a certain way, and you have no recourse but to do as you're told, that's your organisation's fault and nothing else. You can either gain a position where you can make changes, or leave the company. Complaining about a tool that has no influence over your work process really doesn't change anything.
- lmm 4y ago
  > Tools are just slaves to reality, not the other way around. If a legacy top-down organisation wants you do to a certain thing a certain way, and you have no recourse but to do as you're told, that's your organisation's fault and nothing else. You can either gain a position where you can make changes, or leave the company. That's naive; tools influence the way they're used. When a tool defaults to having manager accounts that can change how things get done and developer accounts that can't, it nudges the organisation in that direction.