4 ms·

A poor organization will find out how to fail in many processes. The problems are much deeper than at the scrum level.

by lispm 8y ago

conatus 8y ago
Basically this. If the ecosystem in which scrum (or any process) is embedded is hostile then it will fail. But so will everything else, in time.
mlthoughts2018 8y ago
This just trades one non-falsifiable defense for another. First it’s “no true Scrum implementation would have property X.” Now it’s “any observable badness of Scrum was just ambient badness of an already bad company bleeding into Scrum.”
- lispm 8y ago
  > no true Scrum implementation would have property X. That's not the point. Scrum does not say anything how good your organization is. Scrum won't fix these problems. Thus you can have a great Scrum setup and still fail. Of course you can have bad management and a 'true scrum implementation'. Your mistake is to assume that Scrum fixes all kinds of management practices or that 'true scrum' also means all kinds of other things, which it does not. It's also unlikely that specifically bad management practices are especially caused by Scrum - it might have some negative effects in some organizations - it might have positive effects in some other organizations. Scrum is simply not sufficient to be successful - if we want to be successful Scrum might be a good tool in a certain domain, but we also need to address the other issues/topics/practices/processes. Most of that stuff is very independent from using Scrum or not.
  - mlthoughts2018 8y ago
    What? I don't assume Scrum should or can fix bad management practices. I'm saying adding Scrum to already-bad management practices is like throwing gas on the fire. Scrum doesn't help. Also, if Scrum is only some kind of special snowflake process that only works when applied in sociologically perfect companies, well then it's useless. I'd rather use custom, ad hoc, duct-taped together management practices that get the job done even in the midst of bad corporate sociology.
    - lispm 8y ago
      > What? I don't assume Scrum should or can fix bad management practices. What? Scrum fixes all bad management practices? > I'm saying adding Scrum to already-bad management practices is like throwing gas on the fire. There we need evidence that it is actually so. Haven't seen any convincing data for that. > Scrum doesn't help. The sentence before claimed something else: Scrum makes it worse, quickly. > Also, if Scrum is only some kind of special snowflake process that only works when applied in sociologically perfect companies, well then it's useless. True, but that's not the case. Scrum can be used with advantage in average to good companies - but the reality is that good software product development is not that easy and has many ways to fail - for example the software could have a huge security problem, it could have architectural problems, it might not earn enough money, etc. - nothing which the scrum process will fix. There are many areas on the management and other levels, which scrum does not address: payment, office, product, market, hiring, ethics, ... Scrum is really on a tiny framework addressing a few basic things in small team organization. > I'd rather use custom, ad hoc, duct-taped together management practices that get the job done even in the midst of bad corporate sociology. Personally I'd rather work in a company willing to learn how to successfully develop software in some reproduceable way.
      - mlthoughts2018 8y ago
        > What? Scrum fixes all bad management practices? What are you saying here? I was questioning your original statement that I mistakenly thought Scrum should fix bad management practices. I do not think that, and no part of that is a criticism of Scrum. The criticisms are other things. Your follow-up just seems confused about your own parent comment. > "There we need evidence that it is actually so. Haven't seen any convincing data for that." I've seen a lot of that evidence, in threads like this, in the original post, and also empirical evidence in my own work experience with Scrum as both a developer and a manager across several organizations of various ages and sizes. I'm not asking anyone to take my word for it though. I'm happy to look into randomized controlled studies about effectiveness of engineering teams with or without Scrum. Much like with open-plan offices, I'm confident the evidence shows zero efficacy (despite huge planning overhead costs and time wasters) for using Scrum even after controlling for whatever confounders you think are the scapegoats for Scrum's badness. It's a good thing we don't have to worry about what you've seen as our standard of evidence for discussing this topic, and we're free to make useful written arguments and discussions, like the linked post in the OP, that also appeal to important qualitative aspects of the problem, like how developers are disempowered, or how management always misuses Scrum-related progress tracking data. > "The sentence before claimed something else: Scrum makes it worse, quickly." This is pedantic to the point of making me suspect you're just trolling to argue with anyone who doesn't like Scrum. Yes, indeed, two different sentences claimed two separate but compatible and related things. Shocking! > "True, but that's not the case. Scrum can be used with advantage in average to good companies" You're demanding evidence but then just making equally unsubstantiated claims in the opposite direction. What's to say that instances of well-delivered software you've seen weren't done in spite of Scrum rather than because of it. That would need evidence too. And particularly because Scrum requires a far-reaching and globally prescriptive implementation (e.g. do team planning exactly this way and exactly on this timeline, estimate your workload exactly like this, use exactly these meetings, etc.) it strongly suggests the burden of proof is on Scrum proponents to explain why this is better than customized, individually and organically developed workflows that teams use because they are demonstrably working for them. > "Scrum is really on a tiny framework addressing a few basic things in small team organization." This is abject nonsense. Even a framework that did nothing but prescribe that teams must do some form of estimation every X weeks would be hugely overbearing bloatware. Scrum goes so much further, prescribing a huge overhead of different meetings, a bunch of specific named positions that have to have specific responsibilities in teams, and overbearing principles that superficially look small in writing but really are huge bureaucratic nightmares, like mandating that all teams should be cross-functional, which is totally disconnected from business realities in many cases, especially for teams whose sole business value is highly specialized domain area. > "Personally I'd rather work in a company willing to learn how to successfully develop software in some reproduceable way." This presumes that there always exists some "reproducible way", and that it is one-size-fits-all for the a whole company. You're just denying the premise that customized, situation-specific or team-specific workflows could be the right way. It's fine if you want to deny that claim as a personal preference or opinion, but you're just taking that as your own assumption, and then tacitly basing various claims about the superiority of Scrum on this built-in, hidden assumption.

A poor organization will find out how to fail in many processes. The problems are much deeper than at the scrum level.

by lispm 8y ago

A poor organization will find out how to fail in many processes. The problems are much deeper than at the scrum level.

Basically this. If the ecosystem in which scrum (or any process) is embedded is hostile then it will fail. But so will everything else, in time.

mlthoughts2018 8y ago

This just trades one non-falsifiable defense for another. First it’s “no true Scrum implementation would have property X.” Now it’s “any observable badness of Scrum was just ambient badness of an already bad company bleeding into Scrum.”

lispm 8y ago
> no true Scrum implementation would have property X. That's not the point. Scrum does not say anything how good your organization is. Scrum won't fix these problems. Thus you can have a great Scrum setup and still fail. Of course you can have bad management and a 'true scrum implementation'. Your mistake is to assume that Scrum fixes all kinds of management practices or that 'true scrum' also means all kinds of other things, which it does not. It's also unlikely that specifically bad management practices are especially caused by Scrum - it might have some negative effects in some organizations - it might have positive effects in some other organizations. Scrum is simply not sufficient to be successful - if we want to be successful Scrum might be a good tool in a certain domain, but we also need to address the other issues/topics/practices/processes. Most of that stuff is very independent from using Scrum or not.
- mlthoughts2018 8y ago
  What? I don't assume Scrum should or can fix bad management practices. I'm saying adding Scrum to already-bad management practices is like throwing gas on the fire. Scrum doesn't help. Also, if Scrum is only some kind of special snowflake process that only works when applied in sociologically perfect companies, well then it's useless. I'd rather use custom, ad hoc, duct-taped together management practices that get the job done even in the midst of bad corporate sociology.
  - lispm 8y ago
    > What? I don't assume Scrum should or can fix bad management practices. What? Scrum fixes all bad management practices? > I'm saying adding Scrum to already-bad management practices is like throwing gas on the fire. There we need evidence that it is actually so. Haven't seen any convincing data for that. > Scrum doesn't help. The sentence before claimed something else: Scrum makes it worse, quickly. > Also, if Scrum is only some kind of special snowflake process that only works when applied in sociologically perfect companies, well then it's useless. True, but that's not the case. Scrum can be used with advantage in average to good companies - but the reality is that good software product development is not that easy and has many ways to fail - for example the software could have a huge security problem, it could have architectural problems, it might not earn enough money, etc. - nothing which the scrum process will fix. There are many areas on the management and other levels, which scrum does not address: payment, office, product, market, hiring, ethics, ... Scrum is really on a tiny framework addressing a few basic things in small team organization. > I'd rather use custom, ad hoc, duct-taped together management practices that get the job done even in the midst of bad corporate sociology. Personally I'd rather work in a company willing to learn how to successfully develop software in some reproduceable way.
    - mlthoughts2018 8y ago
      > What? Scrum fixes all bad management practices? What are you saying here? I was questioning your original statement that I mistakenly thought Scrum should fix bad management practices. I do not think that, and no part of that is a criticism of Scrum. The criticisms are other things. Your follow-up just seems confused about your own parent comment. > "There we need evidence that it is actually so. Haven't seen any convincing data for that." I've seen a lot of that evidence, in threads like this, in the original post, and also empirical evidence in my own work experience with Scrum as both a developer and a manager across several organizations of various ages and sizes. I'm not asking anyone to take my word for it though. I'm happy to look into randomized controlled studies about effectiveness of engineering teams with or without Scrum. Much like with open-plan offices, I'm confident the evidence shows zero efficacy (despite huge planning overhead costs and time wasters) for using Scrum even after controlling for whatever confounders you think are the scapegoats for Scrum's badness. It's a good thing we don't have to worry about what you've seen as our standard of evidence for discussing this topic, and we're free to make useful written arguments and discussions, like the linked post in the OP, that also appeal to important qualitative aspects of the problem, like how developers are disempowered, or how management always misuses Scrum-related progress tracking data. > "The sentence before claimed something else: Scrum makes it worse, quickly." This is pedantic to the point of making me suspect you're just trolling to argue with anyone who doesn't like Scrum. Yes, indeed, two different sentences claimed two separate but compatible and related things. Shocking! > "True, but that's not the case. Scrum can be used with advantage in average to good companies" You're demanding evidence but then just making equally unsubstantiated claims in the opposite direction. What's to say that instances of well-delivered software you've seen weren't done in spite of Scrum rather than because of it. That would need evidence too. And particularly because Scrum requires a far-reaching and globally prescriptive implementation (e.g. do team planning exactly this way and exactly on this timeline, estimate your workload exactly like this, use exactly these meetings, etc.) it strongly suggests the burden of proof is on Scrum proponents to explain why this is better than customized, individually and organically developed workflows that teams use because they are demonstrably working for them. > "Scrum is really on a tiny framework addressing a few basic things in small team organization." This is abject nonsense. Even a framework that did nothing but prescribe that teams must do some form of estimation every X weeks would be hugely overbearing bloatware. Scrum goes so much further, prescribing a huge overhead of different meetings, a bunch of specific named positions that have to have specific responsibilities in teams, and overbearing principles that superficially look small in writing but really are huge bureaucratic nightmares, like mandating that all teams should be cross-functional, which is totally disconnected from business realities in many cases, especially for teams whose sole business value is highly specialized domain area. > "Personally I'd rather work in a company willing to learn how to successfully develop software in some reproduceable way." This presumes that there always exists some "reproducible way", and that it is one-size-fits-all for the a whole company. You're just denying the premise that customized, situation-specific or team-specific workflows could be the right way. It's fine if you want to deny that claim as a personal preference or opinion, but you're just taking that as your own assumption, and then tacitly basing various claims about the superiority of Scrum on this built-in, hidden assumption.