4 ms·

But jira is only a tool right? Blaming Atlassian for a poorly led organization seems slightly misguided. At some project size, measured either by software comp

But jira is only a tool right? Blaming Atlassian for a poorly led organization seems slightly misguided. At some project size, measured either by software complexity/interoperability or user base, you will need a tool to manage issues and tasks. What you're talking about is an organization where developers are not empowered - but even empowered developers need an issue tracker or a board of some description. A "management by jira" culture will not be remediated by tooling.

galangalalgol 5y ago
A good tool cannot guarantee good results, but a bad tool can shape its user's behavior in bad ways. The same individual without that tool might have behaved differently. I have seen this in what I call design-by-ticket where all the why and how for a design decision, including design by committee meeting notes, get put in jira tickets.
- jordanbeiber 5y ago
  Totally agree with your first two sentences. However, the final part has nothing to do with jira IMO. You would have the same behavior in these organizations regardless of tool. The dysfunction you describe goes way beyond a single or set of tools.
  - galangalalgol 5y ago
    It is hard to say for sure, but this organization used configuration controlled documents for design documentation before atlassian came along. When they made the switch (and hired oodles of graduates) suddenly about half of them ignore confluence or latex for design, because "jira has markdown". Oh hurray, we have a bad typesetting language mixed in with our bug tracker, lets shove our entire design in there! It is possible this is the influence of the graduates we hired, but it felt like everyone got there together while playing with the new toy.
    - jordanbeiber 5y ago
      Can't but help to feel that what you describe is a breakdown of both organization and work process. It wasn't atlassian that "came along" - someone penned down an agreement and, from what it sounds, there was a lack of clarity both in regards to current and future principles of work and collaboration. What we can do, as devs, to protect ourselves from the madness you describe is to be explicit about our work processes and their purpose. Nothing much, but just a set of agreed upon principles and ways of working which should have nothing to do with tools. What you end up with, by being explicit, is for having "something" to be supported by one or several tools. Makes it easier to evaluate, select and change tooling that is fit for purpose.
      - marcus_holmes 5y ago
        The thing I've found is that Jira has so many fields on its tickets that beg to be filled in, that PMs start filling them in, and before you know it they're all mandatory and must be filled in. And organising that much state in the tickets becomes a full-time job, and so the PM ends up doing that - managing the state of Jira rather than managing the state of the project. The two become synonymous when they're not. When they inevitably diverge all the usual problems of project management get exacerbated horribly (in part because what should happen is all the state in Jira gets thrown away as it doesn't reflect reality, but that's a huge sunk cost so no-one does it). So yeah, I have found that the tool shapes the process, not the other way around. It would probably work the other way around if every organisation built their own project management tooling around their own processes. But that would be insane.
        jordanbeiber 5y ago
        So basically you are describing an organization of people that don't really understand what they should be doing. People led by a tool and not the other way around - and you blame the tool? I hear what you are saying, and I've seen the very symptoms you're describing - I've just stopped chalking it down to the tools. It's a symptom of something entirely different and much more challenging to deal with than a change in tooling.

galangalalgol 5y ago

A good tool cannot guarantee good results, but a bad tool can shape its user's behavior in bad ways. The same individual without that tool might have behaved differently. I have seen this in what I call design-by-ticket where all the why and how for a design decision, including design by committee meeting notes, get put in jira tickets.

jordanbeiber 5y ago
Totally agree with your first two sentences. However, the final part has nothing to do with jira IMO. You would have the same behavior in these organizations regardless of tool. The dysfunction you describe goes way beyond a single or set of tools.
- galangalalgol 5y ago
  It is hard to say for sure, but this organization used configuration controlled documents for design documentation before atlassian came along. When they made the switch (and hired oodles of graduates) suddenly about half of them ignore confluence or latex for design, because "jira has markdown". Oh hurray, we have a bad typesetting language mixed in with our bug tracker, lets shove our entire design in there! It is possible this is the influence of the graduates we hired, but it felt like everyone got there together while playing with the new toy.
  - jordanbeiber 5y ago
    Can't but help to feel that what you describe is a breakdown of both organization and work process. It wasn't atlassian that "came along" - someone penned down an agreement and, from what it sounds, there was a lack of clarity both in regards to current and future principles of work and collaboration. What we can do, as devs, to protect ourselves from the madness you describe is to be explicit about our work processes and their purpose. Nothing much, but just a set of agreed upon principles and ways of working which should have nothing to do with tools. What you end up with, by being explicit, is for having "something" to be supported by one or several tools. Makes it easier to evaluate, select and change tooling that is fit for purpose.
    - marcus_holmes 5y ago
      The thing I've found is that Jira has so many fields on its tickets that beg to be filled in, that PMs start filling them in, and before you know it they're all mandatory and must be filled in. And organising that much state in the tickets becomes a full-time job, and so the PM ends up doing that - managing the state of Jira rather than managing the state of the project. The two become synonymous when they're not. When they inevitably diverge all the usual problems of project management get exacerbated horribly (in part because what should happen is all the state in Jira gets thrown away as it doesn't reflect reality, but that's a huge sunk cost so no-one does it). So yeah, I have found that the tool shapes the process, not the other way around. It would probably work the other way around if every organisation built their own project management tooling around their own processes. But that would be insane.
      - jordanbeiber 5y ago
        So basically you are describing an organization of people that don't really understand what they should be doing. People led by a tool and not the other way around - and you blame the tool? I hear what you are saying, and I've seen the very symptoms you're describing - I've just stopped chalking it down to the tools. It's a symptom of something entirely different and much more challenging to deal with than a change in tooling.