Agile frameworks aren’t the destination. They are the starting points.

Imagine for a second that you decided to take up cooking. Prior to this, the extent of your cooking prowess consisted of grilled cheese sandwiches, instant noodles and, if you were feeling particularly brave, an omelette. But today, for some reason, you decided to grab the cooking bull by the horns and learn how to not only cook for yourself but for others. 

What’s the first thing you do?

You might enroll in a cooking class. You might watch some YouTube videos. Maybe you buy yourself a cookbook. In all of these paths someone is giving you a recipe to follow. Once you procure the ingredients you diligently follow every step of the recipe and arrive at something that may (or may not) resemble the desired outcome.

And then you do it again. And again. And again.

Assuming you didn’t give up you arrive at a point where you’ve got a handle on the basics and start to do a bit of improvising. Maybe you add a little bit of garlic to that omelette. One morning you’re feeling particularly reckless and add a slice of bacon to that grilled cheese sandwich. You try some stuff. It works out. You try other stuff. It doesn’t work out as well. But you’re learning and you keep getting better. The basics become second nature and you’re now pushing your new found cooking abilities to produce increasingly more demanding and, in theory, more rewarding meals. 

Some folks end up becoming actual chefs. They reach a level of mastery where not only are the basics second nature but the recipes are too. They don’t have cookbooks or watch YouTube videos. They have a clear sense of what they’re targeting and have the foundation of core skills and the agility to adjust along the way to ensure they end up with a creation they are proud of. 

Recipes are frameworks. They are step by step guides to achieving an end. Teams that are just starting out with frameworks like Agile (or Scrum to be more exact) are looking for recipes. They read the books, watch the videos and attend the trainings. They begin to execute the recipe as they learned it and get to a point where they can follow the framework consistently. And this is where many stop. They mistake mastering the execution of the framework for mastery of the practice. They become excellent recipe followers but whenever something challenges their accepted view of how “things are done” it is rejected — because it challenges the status quo. In fact, the very agility they set out to achieve is cast aside in favor of rigidly following their chosen framework. 

Frameworks like Scrum are the beginning of your agile transformation. They are the cookbooks. They provide you with an initial path to follow. They are not, however, the destination. In fact, I would argue that simply implementing these recipes is the equivalent of launching a product. It’s an output. The ultimate goal is agility. That is the outcome you and your team are striving for. Looking to other companies for inspiration is the right thing to do. Watching videos about how Spotify implemented their famous ways of working is analogous to watching cooking videos. Emulating what they do, however, without adjusting for your own unique context is, pardon the extended pun, a recipe for disaster. If you loved a recipe you saw online but it included an ingredient you were allergic to, would you still include it? Or would you find a replacement option or an alternative way to cook it? The same is true for your process transformations. Inevitably your organization will be different than Spotify, Atlassian, Amazon or any of the other companies held up as models of modern software development practices. 

Learn the basics. Learn how to follow the recipes. But then also learn how to adjust the recipes to fit your context. Push past the criticism of, “well, that’s not in the scrum guide” and insist on creating a “scrum” process that works for your teams, in your industry with your internal politics and target audience. If you’re lucky, you’ll become a chef and throw away the cookbooks in favor of shared goals and the agility to adjust as new circumstances arise. Isn’t that what being agile is all about?