"The (Pirate's Code) is more what you'd call 'guidelines' than actual rules."

            - Captain Barbossa, Agile pragmatist, Pirates of the Carribean, 2003

One of the more confusing aspects of Scrum for me has been the fact that "adapting" Scrum to fit your team's specific circumstances is always encouraged... but doing something like applying the "Kanban" technique to Scrum upsets many traditionalists.

"The surprising thing for me is that many smart Agile people - people I know to be intelligent insightful people - seem bugged by Kanban... I'm seeing Agile people behave as strangely about Kanban as traditional process folks behaved about Agile. They seem threatened." -- Jeff Patton

I've had a hard time getting some Scrum fundamentalists to even DISCUSS why they feel certain parts of Scrum should be "off limits" to change -- a strange idea, considering that Scrum, as it is typically applied today, is already very different from the way it was originally described. This seems inconsistent with Agile principles that encourage change based on continued analysis and experimentation, especially since the majority of people applying Kanban seem to be experienced Scrum practitioners, who report great success with this Scrum + Kanban approach in solving real-world issues that their teams struggled with under "straight" Scrum.

There is a subculture of agilists who seem to promote an "all or nothing", "enlightened vs. heathen" attitude, reflected in statements along the lines of "if you're not doing X, Y, and Z (or if you try to add Q), you're doing it wrong and you're not Agile". Many senior Agile dev. community members have explicitly spoken out against this, as counter-productive and just plain wrong. Kent Beck included an apology in the preface to the second edition of his book, Extreme Programming Explained, specifically to try to address this for the XP community, and published works by other industry thought leaders including Mary Poppendieck, Alan Shalloway etc. have made similar points. IBM has pushed for ALL its developers to adopt SOME form of agile, while explicitly REJECTING the idea that you need to follow any specific set of practices or methodology.

The Dancing Agile Elephant: IBM Software Group's Transition to Lean and Agile Development

Having worked both in highly-productive start up environments, and some amazingly dysfunctional corporate beauracracies, I'm an absolute supporter of developing software in a way that's consistent with Agile PRINCIPLES, and it is frustrating to think, after finally convincing your corporate management to take a serious look at what Agile has to offer, they'll encounter a discussion space filled with a mixture of hippie-dippy idealism and bickering that's likely just to make them roll their eyes and dismiss the topic out-of-hand.