I like Scrum. I like small releases. I like iterative processes. I like breaking things down into smaller things, that in the end are quite easy to estimate. I like the fact the planning poker pushes us to talk about assumptions and therefore makes us design before we code, instead of design while we code. I've worked in agile processes before Scrum became famous (to me ;-)), just because it felt good in my belly, and that's often all I need to be able to do my work well.

But, there are some things about Scrum that sometimes makes me feel eerie:

First, Scrum is too much a buzzword
Scrum is sometimes more a buzzword than something that is practically used. That's indicated to me when I talk to software developers I know here and there. "We sold the projects as Scrum [because it's the buzz], we call it Scrum [because it's the buzz], but it's really not... [sad look in eye, because Scrum is the buzz]". The project team might struggle to keep Scrum in their project, but because it's not implemented correctly (due to lack of real commitment from management / customer), they end up with a lesser process. In the end the product will suffer.

Second, Pro-Scrum people seems to think that Scrum is the only process in which you can conduct quality software development
I've talked with pro-Scrum people who tried to explain the advantages of Scrum to me. Sort of preaching to the choir, I'd say. However, when I explained about the project setup I was once working in, and that the customer didn't have the agility in their organization and a technical setup that could support the Scrum process, they adviced me to try to sell it in anyways. Ok ok, fair enough and a good idea, I thought. A couple of weeks later, they went on about it again, and I tried to explain again, that the customer couldn't and didn't have it in his priorities to change into Scrum-projects. But it didn't really sink in to these pro-Scrum people - I could see, that they really didn't buy in (or listen) to my arguments. I just got "But it's the best, you've got to! You've got to!", followed by that crazy/orgasmic look in their eyes, that gives me the chills rather than the hots. To me, a process shouldn't become a religion and blur your mind from choosing a process, that really fits the setup. Bop bop... 

Third, no one's realizing that Scrum is often not applicable
Let's say that both management and customers want to commit to Scrum. To have a "true" Scrum project there are some prerequisites, that needs to be fulfilled. First, you need to have a Scrum master and a team that knows and can see the advantages in doing Scrum. Everyone in the producing team must sign up for it, and it's not enough to have the titles in place(!). No, it's not. But even if the project team do recognize the benefits, realize that you just don't have a Scrum project, if the customer doesn't want og cannot sign up for Scrum. Or maybe they can, but don't have the capacity in their organization to support the Scrum Customer-role and to keep up with the short cycles and many releases that Scrum introduces. It's a fair insight. If so, it's not really Scrum. Don't think that you can survive by letting your project manager fake the customer role and do "pseudo-Scrum", while the real customer continues to take showers in the "waterfall" process. It will lead to a shaky incompatible process or maybe no process at all.

Fourth, people do pseudo-Scrum anyways
Please, don't.

Let me hear your comments ... :-)