Scrum is evil because... (part 2)

Posted by ESCOZ on Friday, September 11, 2009

This is the second (and last) poster about why Scrum is evil, created during an open spaces conversation at Agile 2009. The first part of this list can be found here, as well as a list of reasons why Scrum is good.

Scrum is Evil because (part 2):

[caption id=“attachment_33” align=“alignright” width=“150” caption=“Scrum Is Evil – 2”]Scrum Is Evil - 2[/caption]

  • Encourages to stop thinking about process
  • Easy to become micromanagement
  • Has a Scrum "master"
  • Does not fight "the man"
  • Turns great developers into whiners/(??) ?
  • Easy to play blame game
  • Threatens work of good coaches (enforced pyramid scheme)
  • Creates process opportunity cost
  • Alliance did not come here [to Agile 2009]!
  • Dogmatic practitioners
  • Hard to know if you're doing it wrong
  • Ambiguous / contains paradoxes
  • "big bang" Scrum
  • Too advanced for us
  • Assumes responsibility (by developers)
  • lip service to self organized team
  • Focus on Scrum, rather than on product

I don’t think I agree with this list as much as I agree with the first one. Many of the items listed here are more related to bad use of Scrum than the methodology itself (focus on scrum rather than product, easy to become micromanagement, etc). While these problems may reflect the fact that the ScrumMaster training and certification has its own problems, to me its not really a problem with the framework.

Other items in this list have a lot to do with Scrum being used in the enterprise. Why do we have to fight the man? Why would good coaches be threatened by hierarchies? What makes it easy to play blame game? These items to me sound more like personal problems turned into anger with the process than anything else.

The one item in this list that I really like though is that its hard to know if you’re doing it wrong. While this can be true for any Agile methodology, Scrum can be specially vulnerable to this because its really hard to get metrics related to the process itself. There’s no list of items to check as you go along; there’s no numbers you can collect as you go along to check if everything is going well. Scrum depends immensely on the work of the ScrumMaster, and in his experience dealing with issues.

This is my last post in this series about Scrum from Agile 2009, but this topic has been discussed in detail quite a few times already. If you’re interested in more info about this, I specially enjoyed this thread on stack overflow, and this post from Eric Le Frevre. This article from Mike Cohn is also really good at listing a few common smells in your Scrum project.