3 ms·

Because they don't apply universally and managers want them to. Take scrum vs. for example. The focus on small changes, repetitive action, reflective insights

Because they don't apply universally and managers want them to. Take scrum vs. for example. The focus on small changes, repetitive action, reflective insights, and short feedback cycles is absolutely awesome for software maintenance. Use cases like the python 2 migration, Database upgrades, human language translations, or incremental architectural rework are perfectly suited for scrum. You can develop features as well, as long as they are fairly isolated. If you want to add a device driver to the Linux kernel, scrum would probably work very well. But scrum totally breaks down for features that are not independent of each other. Using scrum can easily lead to two features deployed to production that logically cannot coexist under certain circumstances. And no, testing doesn't prevent that. Another problem are features that are just very large by nature. They tend to break the repetitive cycle, because they simply don't repeat. Finally, bugs are often problematic if they cannot be planned into a future sprint because they are urgent. Scrum simply doesn't assume that anything could happen in the middle of the sprint. It's an alien concept. That doesn't make scrum a bad methodology per se, it's just important to consider the use cases and potential exceptions. And to chose another methodology once the exceptions become the norm.

pydry 4y ago
>Using scrum can easily lead to two features deployed to production that logically cannot coexist under certain circumstances. And no, testing doesn't prevent that. Another problem are features that are just very large by nature. They tend to break the repetitive cycle, because they simply don't repeat. Breaking down features is a skill that not many learn because, unless it's trivial, they believe it to be impossible to begin with. Good god is it valuable though. I'm with you on the rest of scrum. It's an awful methodology.
- choeger 4y ago
  Breaking down features doesn't help if two features are simply incompatible with each other. I experienced this once, when feature A that was about 3 years old prevented feature B that was a out 1 year old from functioning correctly. The error lead to accumulation of garbage in a DB and was spotted when said DB ran out of disk space. It was incredible difficult to convey the message to management that the bug was at a meta level because both features worked as specified. They really struggled with the concept. It simply didn't fit their view on reality that features aren't completely independent.
  - pydry 4y ago
    No, definitely not. That should be self evident during a planning session though should it not?

pydry 4y ago

>Using scrum can easily lead to two features deployed to production that logically cannot coexist under certain circumstances. And no, testing doesn't prevent that. Another problem are features that are just very large by nature. They tend to break the repetitive cycle, because they simply don't repeat. Breaking down features is a skill that not many learn because, unless it's trivial, they believe it to be impossible to begin with. Good god is it valuable though. I'm with you on the rest of scrum. It's an awful methodology.

choeger 4y ago
Breaking down features doesn't help if two features are simply incompatible with each other. I experienced this once, when feature A that was about 3 years old prevented feature B that was a out 1 year old from functioning correctly. The error lead to accumulation of garbage in a DB and was spotted when said DB ran out of disk space. It was incredible difficult to convey the message to management that the bug was at a meta level because both features worked as specified. They really struggled with the concept. It simply didn't fit their view on reality that features aren't completely independent.
- pydry 4y ago
  No, definitely not. That should be self evident during a planning session though should it not?