3 ms·

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 attemptin

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.

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.