12 ms·

Scrum isn't good or bad, but the way the OP (or their company) uses it seems to be a reflection of an inflexible culture. For example, the OP argues how scrum

Scrum isn't good or bad, but the way the OP (or their company) uses it seems to be a reflection of an inflexible culture. For example, the OP argues how scrum strips engineers the autonomy they need to get the job done and how it's super inflexible. When we did scrum with my team, the scrum master role was rotated among engineers, growing each of us significantly as professionals. We also made changes to the "core" of scrum after our retrospectives when we decided it was stuff that did not work for us. When management tried to use story points for tracking or forecasting we told them to forget about the whole thing. We added bugfixing sprints after we observed the bugs piling up. I can go on - we made scrum work in an environment where we were empowered to do what makes sense. The crux of the post seems to be that OP has some very rigid management and devs cannot change the mindset. Instead of complaining about scrum, I suggest the OP either try changing the culture from the team level. Or if it won't work, just get out and work at a place where there is sane management who does not drink the rigid scrum kool-aid. Luckily, there are more and more places like that these days.

codemac 8y ago
> Scrum isn't good or bad. There isn't enough evidence-based science on what produces the best software -- but Scrum can be measured against other software practices, and should be.
jstimpfle 8y ago
> Scrum isn't good or bad I must have heard this at least a dozen times in the last months. OOP isn't good or bad, Exceptions aren't good or bad, Scrum isn't good or bad. It makes me mad. Guys and girls! Software is not a contest in being liberal and tolerant. There are methods and techniques that are objectively better than others in reaching most of the goals that are important. You wouldn't contest a F1 driver on a bicycle - not on a race track. And engineers who really know their stuff usually agree on how to build software in a given domain. I do not know of any success stories using Exceptions on Kernels or RDBMSs or even most server software. But I know people have tried, and even they agree it was a bad idea. If you want to say Scrum isn't good or bad, depending on how you tweak it so it sucks less, then I say it's definitely bad. It's not a solid method that helps you reliably reach your goals. If you want to say Scrum isn't good or bad unless metrics are defined (that doesn't seem to be the case here), then you are right, but it's a meaningless statement.
- ploxiln 8y ago
  > OOP isn't good or bad, Exceptions aren't good or bad, Scrum isn't good or bad. It makes me mad. It's all true though. Do whatever you want, all that matters is that you do it well - you just can't simplify a good software engineer down to techniques like these. I recommend reading this piece from a guy who studied software development methodology for over 20 years: http://alistair.cockburn.us/Characterizing+people+as+non-linear,+first-order+components+in+software+development/v/slim http://alistair.cockburn.us/Characterizing+people+as+non-lin...
  - jstimpfle 8y ago
    No. There are very objective reasons why e.g. exceptions do not work for projects of advanced complexity. In short, they add additional, hard to see code paths and a redundant method of result handling (with its own noisy syntax, and new semantics) that brings grand-scheme structural complexity (now EVERY component must be exception-safe, every added feature's behaviour with respect to exceptions must be validated) that affects the whole project. Once you realize it starts to be a problem you cannot fix it anymore because it affects the whole project. This is why bigger projects use less and less features. Using only few features might slow development a little in the small, and you might even make more errors in the small while developping. But you can FIX them. I realize this is not hard science, and I have no motivation to do any on it, like collecting and bending statistics. But as long as all people have to say "XY is not good or bad", "things will get better", "XY has just a very steep learning curve", "you just didn't dance the right dance" and all evidence seems to suggest otherwise, then you've just lost the argument. End of story.
    - barrkel 8y ago
      Exceptions work excellently for business-level server software; typically they make the server transaction all or nothing, with transactional semantics. The stateless nature of HTTP, and transactions provided by the database, usually add up to make this easy. Business logic throws an exception, everything unwinds, the transaction rolls back, no state was modified, and the server returns an error code to the client: all good. When you need partial updates to state in the case of an error, then you're in trouble. When you have multiple transactions to coordinate, but no distributed transaction coordinator, you're in trouble (but you are anyway whether you use exceptions or not). The more state you need to preserve in an error case, the worse exceptions are for your use case. Ideally, exceptions are never caught except at the topmost loop: server request dispatcher, UI event handler, or command line driver. When execution must continue with recovery, exceptions are an inferior tool.
crimsonalucard 8y ago
scrum master is different from product manager. OP was referring to the product manager not the scrum master.
crdoconnor 8y ago
>Scrum isn't good or bad, but the way the OP (or their company) uses it seems to be a reflection of an inflexible culture. It's not the company. This inflexibility is a reflection of scrum's culture. I've seen this inflexibility on multiple teams across the world - what you've experienced is very much the exception and what the OP described is basically the norm. >We also made changes to the "core" of scrum after our retrospectives when we decided it was stuff that did not work for us. This is great and it's exactly how I'd want to work but I think almost every single scrum consultancy not only advocate strongly against doing this, they would likely blame anything that went wrong on your "rash" decision to not adhere to core scrum principles. They literally invented a whole new phrase to emphasize just how much they look down on what you do: https://www.scrum.org/resources/what-scrumbut https://www.scrum.org/resources/what-scrumbut >We added bugfixing sprints after we observed the bugs piling up. This is actually something I've heard explicitly called out by consultancies. >Instead of complaining about scrum, I suggest the OP either try changing the culture I don't agree. I suggest slagging scrum off until it dies, because the inflexibility which you decry is so deeply embedded in its culture and will only die when scrum does. Sure, what you did worked great - it just wasn't "scrum".
coldtea 8y ago
>Scrum isn't good or bad Well, it's either good, bad or ho-hum. If it's bad or ho-hum we shouldn't be doing it. If it's good we should be doing more of it. Now, it's true that a technique can be good but people practice it badly. But first we need to know positively that the technique is good -- before we insist people follow it more carefully. So saying "X isn't food or bad, it's the way you use it" don't help. Saying "X is good, but you're using it wrong" would indeed be helpful (if true).
- jstimpfle 8y ago
  This is all I really wanted to say. You did it much better than me.
hacknat 8y ago
The whole scrum isn’t good or bad thing annoys me. It’s like the people who argue in favor of communism and when you point out its immense failure rate they say, “well that’s not really communism”. Scrum seems to have a very poor implementation rate and seems to draw the ire of most engineers.
- matthewmacleod 8y ago
  Scrum seems to have a very poor implementation rate and seems to draw the ire of most engineers. Engineers are as responsible as any other actor for poor Scrum implementations. Scrum, or any agile method, isn't a silver bullet. It doesn't compensate for bad teams. It's something that teams can use to deal with some common software development issues. It's also not the only tool that can be used for that purpose. Developers pouring ire on "scrum" when they aren't practicing it in the first place are attacking the wrong target.
- throwaway84742 8y ago
  I also take issue with the term “agile” in general. I did not observe it to be any more “agile” than the good ol’ “pile of GitHub issues” method.
- cbsmith 8y ago
  Process, design, and yes... governing is a series of trade offs. You can certainly talk about the merits of the trade offs and whether they are appropriate for a given context, but a critique that fails to understand the trade offs and speaks in strict good/bad interpretations comes across as terribly naive.

codemac 8y ago

> Scrum isn't good or bad. There isn't enough evidence-based science on what produces the best software -- but Scrum can be measured against other software practices, and should be.

jstimpfle 8y ago

> Scrum isn't good or bad I must have heard this at least a dozen times in the last months. OOP isn't good or bad, Exceptions aren't good or bad, Scrum isn't good or bad. It makes me mad. Guys and girls! Software is not a contest in being liberal and tolerant. There are methods and techniques that are objectively better than others in reaching most of the goals that are important. You wouldn't contest a F1 driver on a bicycle - not on a race track. And engineers who really know their stuff usually agree on how to build software in a given domain. I do not know of any success stories using Exceptions on Kernels or RDBMSs or even most server software. But I know people have tried, and even they agree it was a bad idea. If you want to say Scrum isn't good or bad, depending on how you tweak it so it sucks less, then I say it's definitely bad. It's not a solid method that helps you reliably reach your goals. If you want to say Scrum isn't good or bad unless metrics are defined (that doesn't seem to be the case here), then you are right, but it's a meaningless statement.

ploxiln 8y ago
> OOP isn't good or bad, Exceptions aren't good or bad, Scrum isn't good or bad. It makes me mad. It's all true though. Do whatever you want, all that matters is that you do it well - you just can't simplify a good software engineer down to techniques like these. I recommend reading this piece from a guy who studied software development methodology for over 20 years: http://alistair.cockburn.us/Characterizing+people+as+non-linear,+first-order+components+in+software+development/v/slim http://alistair.cockburn.us/Characterizing+people+as+non-lin...
- jstimpfle 8y ago
  No. There are very objective reasons why e.g. exceptions do not work for projects of advanced complexity. In short, they add additional, hard to see code paths and a redundant method of result handling (with its own noisy syntax, and new semantics) that brings grand-scheme structural complexity (now EVERY component must be exception-safe, every added feature's behaviour with respect to exceptions must be validated) that affects the whole project. Once you realize it starts to be a problem you cannot fix it anymore because it affects the whole project. This is why bigger projects use less and less features. Using only few features might slow development a little in the small, and you might even make more errors in the small while developping. But you can FIX them. I realize this is not hard science, and I have no motivation to do any on it, like collecting and bending statistics. But as long as all people have to say "XY is not good or bad", "things will get better", "XY has just a very steep learning curve", "you just didn't dance the right dance" and all evidence seems to suggest otherwise, then you've just lost the argument. End of story.
  - barrkel 8y ago
    Exceptions work excellently for business-level server software; typically they make the server transaction all or nothing, with transactional semantics. The stateless nature of HTTP, and transactions provided by the database, usually add up to make this easy. Business logic throws an exception, everything unwinds, the transaction rolls back, no state was modified, and the server returns an error code to the client: all good. When you need partial updates to state in the case of an error, then you're in trouble. When you have multiple transactions to coordinate, but no distributed transaction coordinator, you're in trouble (but you are anyway whether you use exceptions or not). The more state you need to preserve in an error case, the worse exceptions are for your use case. Ideally, exceptions are never caught except at the topmost loop: server request dispatcher, UI event handler, or command line driver. When execution must continue with recovery, exceptions are an inferior tool.

crimsonalucard 8y ago

scrum master is different from product manager. OP was referring to the product manager not the scrum master.

crdoconnor 8y ago

>Scrum isn't good or bad, but the way the OP (or their company) uses it seems to be a reflection of an inflexible culture. It's not the company. This inflexibility is a reflection of scrum's culture. I've seen this inflexibility on multiple teams across the world - what you've experienced is very much the exception and what the OP described is basically the norm. >We also made changes to the "core" of scrum after our retrospectives when we decided it was stuff that did not work for us. This is great and it's exactly how I'd want to work but I think almost every single scrum consultancy not only advocate strongly against doing this, they would likely blame anything that went wrong on your "rash" decision to not adhere to core scrum principles. They literally invented a whole new phrase to emphasize just how much they look down on what you do: https://www.scrum.org/resources/what-scrumbut https://www.scrum.org/resources/what-scrumbut >We added bugfixing sprints after we observed the bugs piling up. This is actually something I've heard explicitly called out by consultancies. >Instead of complaining about scrum, I suggest the OP either try changing the culture I don't agree. I suggest slagging scrum off until it dies, because the inflexibility which you decry is so deeply embedded in its culture and will only die when scrum does. Sure, what you did worked great - it just wasn't "scrum".

coldtea 8y ago

>Scrum isn't good or bad Well, it's either good, bad or ho-hum. If it's bad or ho-hum we shouldn't be doing it. If it's good we should be doing more of it. Now, it's true that a technique can be good but people practice it badly. But first we need to know positively that the technique is good -- before we insist people follow it more carefully. So saying "X isn't food or bad, it's the way you use it" don't help. Saying "X is good, but you're using it wrong" would indeed be helpful (if true).

jstimpfle 8y ago
This is all I really wanted to say. You did it much better than me.

hacknat 8y ago

The whole scrum isn’t good or bad thing annoys me. It’s like the people who argue in favor of communism and when you point out its immense failure rate they say, “well that’s not really communism”. Scrum seems to have a very poor implementation rate and seems to draw the ire of most engineers.

matthewmacleod 8y ago
Scrum seems to have a very poor implementation rate and seems to draw the ire of most engineers. Engineers are as responsible as any other actor for poor Scrum implementations. Scrum, or any agile method, isn't a silver bullet. It doesn't compensate for bad teams. It's something that teams can use to deal with some common software development issues. It's also not the only tool that can be used for that purpose. Developers pouring ire on "scrum" when they aren't practicing it in the first place are attacking the wrong target.
throwaway84742 8y ago
I also take issue with the term “agile” in general. I did not observe it to be any more “agile” than the good ol’ “pile of GitHub issues” method.
cbsmith 8y ago
Process, design, and yes... governing is a series of trade offs. You can certainly talk about the merits of the trade offs and whether they are appropriate for a given context, but a critique that fails to understand the trade offs and speaks in strict good/bad interpretations comes across as terribly naive.