4 ms·

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

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
    I'm comparing Scrum to customized, situation-specific workflow practices created and adopted by the team that will use them, based on what works for that team. What about Scrum uses evidence to convince a team to believe it should deviate from that? > "No one cares whether you approve of Scrum or not." If you don't want to participate in a discussion about it, why are you? Statements like this are useless. We're talking about high-level evaluation of Scrum. It's like you would read the original post in the OP, which is a qualitative discussion. And instead of formulating reasonable discussion points, you'd just leave a comment saying, "No one cares what you think." At that point, I mean, your opinion's decided. Why are you even here? What is the goal? To shoot down anyone who tries to analyze Scrum in a bigger picture sense and just give them a raspberry?
    - nradov 8y ago
      You're comparing Scrum to a phantom. State which specific practices work better than Scrum in specific situations. Otherwise it's just a complaint with no useful contribution.
      - mlthoughts2018 8y ago
        > "State which specific practices work better than Scrum in specific situations." Sure. - When working on a team whose primary outputs are highly specialized research, the necessity to have planning meetings, standups, retrospectives, etc., according to a single fixed schedule causes a lot of problems. A better practice is to allow the length of a sprint to be variable and to be different for different individual team members depending on what they are working on. Elminate overhead that's not helping by discontinuing a fixed-cycle planning meeting (e.g. don't do it every X weeks, rather just arrange planning meetings in an ad hoc way whenever enough items reach a state where a group planning meeting makes sense.) If your team is working on projects that need a longer time to ruminate and develop at the moment, then cancel the retrospective meeting and just do it later after some other milestone. Basically, treat these things like collegial, flexible, malleable tools whose timelines and cadence flexibly changes all the time in response to current projects. - When working on fundamental research, notions of incremental progress are not useful. You might spend weeks on a problem and have no demonstrable new functionality. You may not even have any research or documentation to share. You might only be able to say, "I worked extremely hard on methods X, Y, and Z, and I appear no closer to know whether they could work or not. Need more time." So in this situation, estimating story points is absurd, and reporting velocity is at best a nuisance but more often harmful because you can count on upper management questioning it with inappropriate comparisons to the way velocity works for iterative software work. Later on, maybe several weeks later, you might have a breakthrough on the tough research project, and now you are at a point where you need to productionize the supporting software that wraps it, and you do get value from estimating time to completion and using iterative cycles of incremental, demonstrable units of functionality. So once again, it should be flexible. Many times, there is no use whatsoever to estimate story points, so don't do it. Don't use a concept like velocity for these case-by-case situations at all. Then later, if you find value in switching back to an estimation-and-velocity approach for productionizing it, then do so. I could go on, but the general idea is that it should be highly flexible. No fixed set of meetings that must happen every sprint no matter the work context. No enforced policy of always estimating story points or always tracking velocity. That's no flexible, it's rigid because it says you always have to do it that one way, and leaves no room for situations when that one way is not useful, or when it adds costly and time-wasting overhead during periods of work that don't benefit from it. These things should be left up to the team to decide, based on what type of work the team does, how it varies over time, what feels low-overhead and liberating, what facilitates productivity for that team. > "You're comparing Scrum to a phantom." No, I'm not. And I have not been at any point in earlier comments either. Your comments are just needlessly antagonistic while constantly deflecting without dealing with the fundamental problems of Scrum. > "Otherwise it's just a complaint with no useful contribution." Complaints are often useful contributions all on their own. It's foolish to claim that complaints have to always be accompanied by candidate solutions to be useful. No. Knowledge of the details of the complaint is useful all on its own. Regardless though, this is still a lazy mischaracterization of anything I have been writing.
- conatus 8y ago
  Well all I can say is that I've seen multiple teams implement scrum and this improve overall team productivity, usefulness to the wider organisation and general happiness amongst all members of the team. I have no evidence to suggest that it was anything but adding the framework to the mix that caused these effects. And the more the processes were adhered to by the letter of the framework (i.e. all meetings were adhered to, stand ups were understood well etc), the better the results have been. Of course one could argue that the improvements were the result of some other phenomena. But it certainly seems that the equation seems to have worked and turned teams around. Scrum wasn't in the mix before and now it is things are much improved. By the way I'd in no way advocate a one-size fits all solution. Sometimes other techniques might be as effective or more effective. I'd not say you should agree another way is definitely better if your team is humming along. Why would I?
  - mlthoughts2018 8y ago
    I wish more Scrum-advocates shared your opinion. Hey, if Scrum is working for some team, I would be the last person to ask them to change it. I know how much I hate it when I have a workflow that is succeeding and then management arbitrarily makes me switch to Scrum. So I would not want to do that to people who are doing great with Scrum. The reason I feel the need to deeply question it though, is that most managers don't express the attitude you expressed. Most often they see a workflow as something they need to enforce unilaterally, and that it should function to commoditize the underlying teams. Given that this is how it's practiced almost everywhere, it's fair to ask why is that? Is there anything intrinsic to Scrum that makes that mistake easier? Or at least, is there something Scrum lacks which would make that mistake harder? And then to finally ask if someone is advocating for everyone to be happy switching to Scrum, and advocating that every possible problem with Scrum is not Scrum's fault but always just the misapplication of Scrum (like they are interpreting a religious text or something), then I think it's fair for me to say, "prove it" and ask for evidence that the extra operational overhead of Scrum is empirically shown to be cost-effective.
    - conatus 8y ago
      Doubtless scrum can be imposed from above as a management tactic. This would open to more wider discussions about how power operates in workplaces. I don't know if there is anything intrinsic to Scrum that makes this more common as imposition but there are certainly risks involved in it that can push a negative power dynamic that is certainly possible in any undemocratic workplace. I'd have to reflect on this a bit more before answering. But in a couple of cases I've seen it was sought by the team "from below" to protect the quality of their work, make work more enjoyable and self-organised and basically work to more reasonable timescales. There is something to scrum being a toolbox you can use and having a brand. It means you can ask for a process and people know what you mean. Rather than say "I wish work was better".

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
  I'm comparing Scrum to customized, situation-specific workflow practices created and adopted by the team that will use them, based on what works for that team. What about Scrum uses evidence to convince a team to believe it should deviate from that? > "No one cares whether you approve of Scrum or not." If you don't want to participate in a discussion about it, why are you? Statements like this are useless. We're talking about high-level evaluation of Scrum. It's like you would read the original post in the OP, which is a qualitative discussion. And instead of formulating reasonable discussion points, you'd just leave a comment saying, "No one cares what you think." At that point, I mean, your opinion's decided. Why are you even here? What is the goal? To shoot down anyone who tries to analyze Scrum in a bigger picture sense and just give them a raspberry?
  - nradov 8y ago
    You're comparing Scrum to a phantom. State which specific practices work better than Scrum in specific situations. Otherwise it's just a complaint with no useful contribution.
    - mlthoughts2018 8y ago
      > "State which specific practices work better than Scrum in specific situations." Sure. - When working on a team whose primary outputs are highly specialized research, the necessity to have planning meetings, standups, retrospectives, etc., according to a single fixed schedule causes a lot of problems. A better practice is to allow the length of a sprint to be variable and to be different for different individual team members depending on what they are working on. Elminate overhead that's not helping by discontinuing a fixed-cycle planning meeting (e.g. don't do it every X weeks, rather just arrange planning meetings in an ad hoc way whenever enough items reach a state where a group planning meeting makes sense.) If your team is working on projects that need a longer time to ruminate and develop at the moment, then cancel the retrospective meeting and just do it later after some other milestone. Basically, treat these things like collegial, flexible, malleable tools whose timelines and cadence flexibly changes all the time in response to current projects. - When working on fundamental research, notions of incremental progress are not useful. You might spend weeks on a problem and have no demonstrable new functionality. You may not even have any research or documentation to share. You might only be able to say, "I worked extremely hard on methods X, Y, and Z, and I appear no closer to know whether they could work or not. Need more time." So in this situation, estimating story points is absurd, and reporting velocity is at best a nuisance but more often harmful because you can count on upper management questioning it with inappropriate comparisons to the way velocity works for iterative software work. Later on, maybe several weeks later, you might have a breakthrough on the tough research project, and now you are at a point where you need to productionize the supporting software that wraps it, and you do get value from estimating time to completion and using iterative cycles of incremental, demonstrable units of functionality. So once again, it should be flexible. Many times, there is no use whatsoever to estimate story points, so don't do it. Don't use a concept like velocity for these case-by-case situations at all. Then later, if you find value in switching back to an estimation-and-velocity approach for productionizing it, then do so. I could go on, but the general idea is that it should be highly flexible. No fixed set of meetings that must happen every sprint no matter the work context. No enforced policy of always estimating story points or always tracking velocity. That's no flexible, it's rigid because it says you always have to do it that one way, and leaves no room for situations when that one way is not useful, or when it adds costly and time-wasting overhead during periods of work that don't benefit from it. These things should be left up to the team to decide, based on what type of work the team does, how it varies over time, what feels low-overhead and liberating, what facilitates productivity for that team. > "You're comparing Scrum to a phantom." No, I'm not. And I have not been at any point in earlier comments either. Your comments are just needlessly antagonistic while constantly deflecting without dealing with the fundamental problems of Scrum. > "Otherwise it's just a complaint with no useful contribution." Complaints are often useful contributions all on their own. It's foolish to claim that complaints have to always be accompanied by candidate solutions to be useful. No. Knowledge of the details of the complaint is useful all on its own. Regardless though, this is still a lazy mischaracterization of anything I have been writing.
conatus 8y ago
Well all I can say is that I've seen multiple teams implement scrum and this improve overall team productivity, usefulness to the wider organisation and general happiness amongst all members of the team. I have no evidence to suggest that it was anything but adding the framework to the mix that caused these effects. And the more the processes were adhered to by the letter of the framework (i.e. all meetings were adhered to, stand ups were understood well etc), the better the results have been. Of course one could argue that the improvements were the result of some other phenomena. But it certainly seems that the equation seems to have worked and turned teams around. Scrum wasn't in the mix before and now it is things are much improved. By the way I'd in no way advocate a one-size fits all solution. Sometimes other techniques might be as effective or more effective. I'd not say you should agree another way is definitely better if your team is humming along. Why would I?
- mlthoughts2018 8y ago
  I wish more Scrum-advocates shared your opinion. Hey, if Scrum is working for some team, I would be the last person to ask them to change it. I know how much I hate it when I have a workflow that is succeeding and then management arbitrarily makes me switch to Scrum. So I would not want to do that to people who are doing great with Scrum. The reason I feel the need to deeply question it though, is that most managers don't express the attitude you expressed. Most often they see a workflow as something they need to enforce unilaterally, and that it should function to commoditize the underlying teams. Given that this is how it's practiced almost everywhere, it's fair to ask why is that? Is there anything intrinsic to Scrum that makes that mistake easier? Or at least, is there something Scrum lacks which would make that mistake harder? And then to finally ask if someone is advocating for everyone to be happy switching to Scrum, and advocating that every possible problem with Scrum is not Scrum's fault but always just the misapplication of Scrum (like they are interpreting a religious text or something), then I think it's fair for me to say, "prove it" and ask for evidence that the extra operational overhead of Scrum is empirically shown to be cost-effective.
  - conatus 8y ago
    Doubtless scrum can be imposed from above as a management tactic. This would open to more wider discussions about how power operates in workplaces. I don't know if there is anything intrinsic to Scrum that makes this more common as imposition but there are certainly risks involved in it that can push a negative power dynamic that is certainly possible in any undemocratic workplace. I'd have to reflect on this a bit more before answering. But in a couple of cases I've seen it was sought by the team "from below" to protect the quality of their work, make work more enjoyable and self-organised and basically work to more reasonable timescales. There is something to scrum being a toolbox you can use and having a brand. It means you can ask for a process and people know what you mean. Rather than say "I wish work was better".