> Scrum is not opinionated about the actual development methodology so claims about how it affects the code that is written are themselves a bad smell IMO. Scr

> Scrum is not opinionated about the actual development methodology so claims about how it affects the code that is written are themselves a bad smell IMO. Scrum is actually part of the problem, IMO. I've seen many teams turn scrum into a hammer and treat all future problems as nails. Example problem: The foobar story has failed failed for the third sprint in a row. Likely discussed in retrospective (plausibly good ideas, mind you): - We need to break down stories more before we estimate them. - Or we need to stop underestimating foobar stories. - Or we need to focus on unblocking subtasks related to foobar stories. Probably unconsidered: - The foobar code is a mess and needs to be refactored. - Or the foobar subsystem is too coupled to the Fizzbuzz subsystem. - Or the need for some developer tools to increase productivity in the foobar ecosystem. Since scrum is methodology oriented, methodology is the first tool teams reach for when a problem is encountered. And I see this after team leads make it explicitly OK to discuss technical subjects in retrospectives. I'm not a psychologist, so I can't describe why this phenomenon happens, but I see it regularly.