Posted by ESCOZ on Thursday, September 03, 2009
The last day of Agile 2009 was very different from the other days. Most people had already left the conference, but those few hundreds who stayed were presented with a really fun Open Spaces day, with many discussions and presentations going on at the same time. Remainders of previous presentations decorated the walls and tables all around as people walked all over trying to find the right discussion to participate.
One of those remainders was a list titled "SCRUM is Evil Because..." (picture below). I did not participate in creating the list, but I've had this conversation with friends who are CSM and CSP many times in the past, and this list basically lists , so I took the pictures. I you did participate, please let me know, I would love to add your name here!
Here goes the first part of the list:
Scrum Is Evil Because:[caption id="attachment_29" align="alignright" width="150" caption="Scrum Is Evil"][/caption]
- It won't solve problems
- Ignores good code practices
- Ritual over principle
- Just a "buzzword" with no meaning
- Certification pyramid scheme
- False sense of agility
- Constrains too much
- Process over people
- Strict roles
- Promises [things] it can't keep
- Implies barrier between customer and team
- Commitment over collaboration
- 30 days is too long
- Does not include XP
- Language encourages non-sustainable pace
- ScrumButs are a bad thing
- Mandates "small[?? can't really understand the slide] status meeting
Now, before people start complaining, there was also a "SCRUM is Good Because..." list, which I'll post up in the next few days. There was also, though, another list as big as this one with more "evil" stuff (that will come later as well).
I agree with most of the items in the list above, and my bet is that most experienced Agile coaches and team members probably also do so. Many of the things in the list above, though, make it easier for people to move from waterfall processes to Agile, which ends up being a good thing.
The lack of technical practices (other than saying "high quality is important") is probably the biggest problem I see in that list: the risk created by building incrementally without a clear understanding of the practices needed to maintain the real quality of the project can be as high as the old waterfall. I do understand that Scrum is a generic, non-software specific process, but I don't think that is an excuse for not listing things like continuous inspection, automated testing and so on.