Why <insert any philosophy> is a bad way to build software when you use it in <insert a bad way/abuse of the philosophy>. SDLC procedures have to interpreted co

Why <insert any philosophy> is a bad way to build software when you use it in <insert a bad way/abuse of the philosophy>. SDLC procedures have to interpreted correctly, their philosophy understood and its application to your organization investigated (e.g. Is your scrum team really cross functional?, can your work be divided into meaningful chunks? etc.). Agile practices are hard to understand and grasp, even harder to implement in a clockwork fashion unless you invest a huge amount of discipline and at the same time flexibility. Scrum is even harder to do correctly and there is no one size-fit all recipe for it. Scrum should promote testing of features so better integration of a test team inside a scrum cycle should be possible, it invokes good discussions under pre-planning to come up with backlog tasks, Scrum master role is meant to be transferable if the designated person is not available, Scrum also focuses a lot on metrics and the idea is to gather that data, understand what process improvements are needed and do the next Scrum incrementally better. Now all of this may not work in your organization, something else will maybe. It's not the fault of this particular SDLC.