4 ms·
It’s often impossible to talk productively about this because of all the No True Scotsman fallacies uses to defend Scrum, e.g.: “No true Scrum master would do
by mlthoughts2018 8y ago
It’s often impossible to talk productively about this because of all the No True Scotsman fallacies uses to defend Scrum, e.g.:
“No true Scrum master would do X.”
“A product owner who doesn’t Z is just a bad product owner. Not Scrum’s fault.”
“If X is disempowering people then X is not Scrum.”
These are not valid defenses, and they just distract us from the elephant in the room, which is Scrum’s constant presence everywhere these problems occur.
At some point if the tool cannot do its basic job without requiring perfectly scrupulous product managers and “real” Scrum masters, etc., then it’s Scrum’s fault, and we need to think of less prescriptive, less inflexible models that cannot be so easily subverted politically to merely pay lip service to technical quality, while bastardizing reasonable principles to serve quarterly JIRA datamining expeditions and Dilbert-style management practices.
- mindcrime 8y agoOxygen is also present everywhere these problems occur, so clearly oxygen is at fault...
- mlthoughts2018 8y agoSomeone proposes a mechanism by which Scrum is problematic. “In Scrum, product owners ought to empower the team to advocate for technical quality, but in many Scrums, this does not happen, and short-term, quality-ignorant changes to the timeline rule instead.” This is a claim about the mechanism of Scrum’s failure. And in response someone offers a non-falsifiable defense, like, “whenever that occurs, it’s always the company’s pre-existing badness to blame. Never Scrum.” Can you really not see how this is completely different from an unqualified claim that correlation implies causation? Your comment comes off like you think it has some rhetorical punch, but I invite you to reconsider that you migh have completely missed the entire point.