Scrum is evil because… (part 1)
By ESCOZ posted September 3rd, 2009The 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:
Scrum Is Evil
- 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.
Filed under: Agile | Tags: Agile, Agile2009, Scrum | 3 Comments »
I think one of the problems with Scrum is not necessarily that it does NOT list any good engineering practices to follow (which I agree, it doesn’t) it’s that it only IMPLIES that they are needed.
For me the (engineering) practices that drive quality are worked into the “done” portion of the “process”. A decent “definition of done” must be defined by the team and here is where the engineering practices are brought in (and anything else the team deems will drive quality).
Teams should go through an exercise of defining a “done list” and I believe it is the ScrumMaster’s responsibility to ensure that this list is done, and is reasonably thorough. And by thorough I mean include things like “code reviewed” and “90% automated unit test coverage” etc…
Also, one would hope that during retrospectives team members would raise concerns about the lack of engineering practices and introduce them, especially if these lacking practices are leading to technical debt of some sort. And if team members don’t raise the alarm, it should definitely fall to the SM to raise it, and suggest introducing some practices.
All in all I think one must remember that, for me anyway, Scrum is a set of guideline, a starting point, not the law, adaptation is part and parcel of the process, but with the proviso that these adaptions must not be used to hide a problem, but rather to improve quality.
Just my thoughts…
Congratulations, my great friend, this is a good topic for discussions
I agree with some points.. there’s no single methodology. My company uses a collection of practices from some methodologies and this collection is good for us, but it may not be good for others. Bottom line, there’s no silver bullet out there that can kill all your problems.
Hi Rick,
I totally agree with you! My hope was that every Scrum Master out there would think the same way.
Unfortunately, that’s not the message that is being sent around in scrum trainings and meetings. More and more I’ve seen project managers turned into Scrum Masters, and those usually have no software background, and have no idea what TDD or CI means. I’ve been training a few old-school managers who have been thru the CSM, and still know zero about all this.
That knowledge is essential for this role, in my point of view, but it seems nowadays accepted in the Scrum world to just bypass all that and focus on the iterations. My guess is that soon enough they’ll create a new role in Scrum: Development Master.