A good friend of mine commented on an article by Giles Bowkett entitled, “Why Scrum Should Basically Just Die In A Fire.” Naturally, I was intrigued.
The guy he quoted has had some majorly bad experiences in his software organization which he wrongfully attributes to Scrum.
His conclusion: Scrum should be killed with fire.
His frustrations seem to have come from individuals and relational dysfunctions during Scrum events and misuse of Scrum artifacts; yet he should really take a hint from what my friend said in his Facebook comment:
“Smart people create the processes necessary to do the work, end of story.” – my smart yet anonymous friend
I agree wholeheartedly and if the OP agreed, he would flambe not Scrum but the people in his examples and their highly dysfunctional behavior. The irony is, if the OP was given the power to annihilate Scrum from past, present and future history, the source of his problem would remain. This is because…
Scrum never fails, but people do.
Saying Scrum has failed is like saying my tool belt failed to hammer in a screw. Scrum is a methodology and cannot itself produce working software. It is used by developers to construct agile processes that best enable them to address complex adaptive problems. Producing working and valuable software is just such a problem.
People can also fail when they force their developers to adopt Scrum at all costs. This violates value #1 on the Agile Manifesto.
I would go so far as to say that Scrum is something a team should transition through instead of to if only by a little bit. If teams and organization hang out in Scrum land too long without questioning it or seeking to improve on it, they risk becoming religious zealots instead of creative problem solvers. Also…
Scrum is not for everyone.
If Scrum is not right for a team or organization, it should be discarded in part or as a whole. Holding on to a methodology at odds with a culture or set of good practices is likewise a sign if immaturity, not of Scrum but of the people choosing to implement it.