I’ve used this analogy a couple of times when explaining agile adoption, specifically Scrum, to folks so I wanted to put it here for reference.
Imagine for a minute that you’ve never baked a cake before but you want to learn how. I give you a recipe to follow, it’s my grandmothers recipe and everyone agrees she makes killer cake, and it’s simple so I know it’s a good one for you to start with. You take a look at the recipe and say, “I actually don’t like to use flour so I’m going to skip that”. Then you mention that vegetable oil isn’t really something you use so you’re going to substitute cooking spray instead. You mix things up, bake it, and the cake comes out a mess. You throw your hands up in disgust and announce that cake baking is horrible and doesn’t work. Was there anything wrong with the recipe? Or was it just your inability to follow it that created the outcome you got? Who’s responsible for the failure?
Going by the book allows for an understanding of all the pieces; how they operate, what their intent is, and why they’re important. You can’t simply start replacing bits and pieces without all that understanding or you’re likely to spoil the outcome. Scrum works. Scrummerfall or Waterscrum or whatever kind of duct-tape and bailing wire setup you’ve cobbled together may, or may not, work. But that’s not the fault of the process that you’ve cribbed from. To be fair, I do understand that there are challenges that each environment presents. We can’t always get the support we need to make everything happen but let’s lay the blame where it belongs; us not the process. The whole purpose of Scrum is to make these things visible so you can deal with them and get moving on the things that create real value.