4 ms·

Well, sure it stumbles into this fallacy but so does the roll out of any process involving humans that has a set of normative criteria with a given critique in

Well, sure it stumbles into this fallacy but so does the roll out of any process involving humans that has a set of normative criteria with a given critique in hand. I always feel this fallacy is a weak response as norms can always be applied well or less well. This is what makes them norms. I've seen it work very well. I've seen it work badly. Where it has worked badly it was because the process was not fully understood, badly implemented and not iterated upon. For reasons I can detail on reflection. These are explicable and fixable reasons that given the right company ecosystem and desire to honestly reflect upon them and fix them could have been fixed. A bad process tout court would never see highly effective result in some cases.

mlthoughts2018 8y ago
But if a given norm is always applied badly, it’s disingenuous to say it’s not the norm’s fault. It obviously is. Even if it’s a good norm in theory, if it doesn’t survive contact with human sociology in practice, then it’s disingenuous verbal gymnastics to say “but the norm itself is good, it was just misapplied constantly and nobody, despite huge effort, could stop it from being misapplied.” And Scrum is misapplied so often that this clearly applies, and renders whatever “spirit” of “true” Scrum irrelevant.
- nradov 8y ago
  The norms aren't always applied badly. I have existence proofs of the norms being applied well in multiple different teams.
  - mlthoughts2018 8y ago
    Quoting from my parent comment, > "And Scrum is misapplied so often that this clearly applies ..." It's not about always being misapplied. Just that it's misapplied so often that in the larger scale decision making, it's a problem with Scrum. I don't deny there are isolated examples in which Scrum is applied well and works well. I also don't care, unless those examples represent the majority of cases in most average companies.
    - conatus 8y ago
      Seems you are shakey ground, without empirical justification, to say that in the majority of cases when applied scrum goes badly. We are probably at the point of trading ancedotes, but I'd say in the majority of cases where I have seen it applied it has worked more than it has not. Even a poor implementation has yielded some benefits. And those pieces that have not worked there are reasons why.
      - mlthoughts2018 8y ago
        I agree we might be at the point of trading anecdotes. I would suggest though that there could be the problem that a team works hard to produce good outputs in spite of Scrum, rather than because of it. My feeling, as I have mentioned elsewhere is that this burden of proof is on Scrum and Scrum proponents to back up the claim that it facilitates better business outcomes than would otherwise have been obtained without Scrum. The reason I think it's fair that Scrum has the burden of proof is that it is so far-reaching and overbearing in its degree of prescripting exactly the manner of working. Scrum as a system is responsible for micromanaged enforcement of exactly one set of meetings, exactly one cadence of work, special new positions with Scrum-specific job duties, constraints on team structure, like cross-functionality and minimizing specialization, that there must be some form of aggregateable workload estimation, etc., all which are part and parcel with every Scrum implementation I've heard of (meaning that whether all these prescriptions are explicitly listed in some Scrum manifesto or not, they are absolutely a part of Scrum). Given all this costly overhead and one-size-fits-all prescription, I think it's very fair to say, "prove it." If I know that my team works really well in our own ad hoc way that is tailored to our specializations, our current workload, our preferences, the way we jell as a team, etc., then why should I agree this other way is definitely, empirically going to be better? I'm not saying any other team should use the custom methods my team has found to be productive. But why would we need to give them up for a system nobody has proven to be better, and many people have argued to be worse?
        nradov 8y ago
        There is no particular burden of proof. No one cares whether you approve of Scrum or not. But what are you comparing Scrum to? Define your specific objections and propose an alternative.

mlthoughts2018 8y ago

But if a given norm is always applied badly, it’s disingenuous to say it’s not the norm’s fault. It obviously is. Even if it’s a good norm in theory, if it doesn’t survive contact with human sociology in practice, then it’s disingenuous verbal gymnastics to say “but the norm itself is good, it was just misapplied constantly and nobody, despite huge effort, could stop it from being misapplied.” And Scrum is misapplied so often that this clearly applies, and renders whatever “spirit” of “true” Scrum irrelevant.

nradov 8y ago
The norms aren't always applied badly. I have existence proofs of the norms being applied well in multiple different teams.
- mlthoughts2018 8y ago
  Quoting from my parent comment, > "And Scrum is misapplied so often that this clearly applies ..." It's not about always being misapplied. Just that it's misapplied so often that in the larger scale decision making, it's a problem with Scrum. I don't deny there are isolated examples in which Scrum is applied well and works well. I also don't care, unless those examples represent the majority of cases in most average companies.
  - conatus 8y ago
    Seems you are shakey ground, without empirical justification, to say that in the majority of cases when applied scrum goes badly. We are probably at the point of trading ancedotes, but I'd say in the majority of cases where I have seen it applied it has worked more than it has not. Even a poor implementation has yielded some benefits. And those pieces that have not worked there are reasons why.
    - mlthoughts2018 8y ago
      I agree we might be at the point of trading anecdotes. I would suggest though that there could be the problem that a team works hard to produce good outputs in spite of Scrum, rather than because of it. My feeling, as I have mentioned elsewhere is that this burden of proof is on Scrum and Scrum proponents to back up the claim that it facilitates better business outcomes than would otherwise have been obtained without Scrum. The reason I think it's fair that Scrum has the burden of proof is that it is so far-reaching and overbearing in its degree of prescripting exactly the manner of working. Scrum as a system is responsible for micromanaged enforcement of exactly one set of meetings, exactly one cadence of work, special new positions with Scrum-specific job duties, constraints on team structure, like cross-functionality and minimizing specialization, that there must be some form of aggregateable workload estimation, etc., all which are part and parcel with every Scrum implementation I've heard of (meaning that whether all these prescriptions are explicitly listed in some Scrum manifesto or not, they are absolutely a part of Scrum). Given all this costly overhead and one-size-fits-all prescription, I think it's very fair to say, "prove it." If I know that my team works really well in our own ad hoc way that is tailored to our specializations, our current workload, our preferences, the way we jell as a team, etc., then why should I agree this other way is definitely, empirically going to be better? I'm not saying any other team should use the custom methods my team has found to be productive. But why would we need to give them up for a system nobody has proven to be better, and many people have argued to be worse?
      - nradov 8y ago
        There is no particular burden of proof. No one cares whether you approve of Scrum or not. But what are you comparing Scrum to? Define your specific objections and propose an alternative.