It's like this: Agile is all about dynamic process tailoring. That means, yes, that teams control the degree of paperwork and process they need to accomplish. But it's also like this: there are some "recipes" that the community has found over and over again that work. You'd be a complete fool to ignore them.
For Agile (whatever that is) it may be true. Many of the Scrum books I've seen, however, emphasize that Scrum is an all-or-nothing proposition. Either you get buy in from management and you go Scrum all the way or you don't do Scrum at all. The justification given is that Scrum is a set of interlocking practices, and adopting some of the practices without adopting the whole set doesn't get you any benefit, and may even harm the project.
I have always viewed scrum as a management technique... easily wrapped around delivering a software product. Since scrum is pretty light-weight, I guess doing it "all" is not that cumbersome, but you could probably jettison/modify some parts that don't fit your culture/context. (Just know why...)
4 comments
[ 6.6 ms ] story [ 25.4 ms ] threadFor Agile (whatever that is) it may be true. Many of the Scrum books I've seen, however, emphasize that Scrum is an all-or-nothing proposition. Either you get buy in from management and you go Scrum all the way or you don't do Scrum at all. The justification given is that Scrum is a set of interlocking practices, and adopting some of the practices without adopting the whole set doesn't get you any benefit, and may even harm the project.