Are You Cooking Your Pears Correctly? - On Following Agile Recipes

Not long ago, Noah, one of our developers, shared a video with us where famous chef Jacques Pépin talks about what it means to follow a recipe.

In this video, he makes the point that a recipe reflects what someone needed to do under certain conditions at a certain point in time. In this case, it's cooking a pear dessert.

There are many variables, however, in what makes for an optimal way to cook the pears to make the dessert. What kind of pears are you using? What kind of equipment? At what elevation are you cooking the pears? What's the temperature and humidity of your surroundings? What flavors do your eaters enjoy?

If any of those factors are different for you than when the person was writing the recipe, your results are going to be different. Someone wrote the recipe under a specific set of circumstances that may not match your own. That doesn't mean the results are going to be wildly different, necessarily, but it does mean that you can't follow the recipe to the letter and expect the dish to turn out the same way. You either need to adjust the recipe to fit your circumstances or be okay with the fact that your dish will be different (potentially better!) than the dish the recipe was designed to create.

Organizations need to have the same perspective when following agile "recipes."

One thing our company challenges regularly is this idea: if a given set of practices produced good results for Company A, then you could drop them right onto Company B and get the same results.

In our experience working with various organizations, this consistently proves to be false. Just because it worked for Toyota or Spotify or Dean Leffingwell does not mean it will do the same thing for you if you follow it to the letter. The same practices that do wonders for a streaming music service may not be the best practices for a hospital.

In the same way, it's risky to assume following a defined body of practices like Scrum or SAFe to the letter is the best thing your organization could do. Those methodologies (and others like them - don't mean to pick on those two) were developed around a certain set of assumptions at a certain point in time. Is your work force distributed over widely different time zones? Is your work variable or pretty much the same thing all the time? Are you creating software for the open market or is it a line of business application meant for internal use? All those things and more may suggest that you need to modify what "the book" says or what you learned in your certification course in order to increase your agility.

So, are predefined practices like Scrum or Kanban worthless?

Absolutely not. Jacques Pépin does not recommend burning all your recipe books and making your dishes entirely without guidance, nor would I recommend burning all your agile books or never taking a certification course.

The value of recipes is that they give us a lot of valuable guidance that gets us a long way towards the results that we want. We don't have to reinvent everything through trial and error. The recipes give us a default way to proceed, typically written by someone who has been successful, to move us toward our goal.

But the point of following a recipe isn't to follow a recipe. If your pear dish is terrible, nobody is going to care how fastidiously you followed the recipe. The point is to have a delicious dessert, and to get there, you may have to adjust the recipe. Cook this a little longer. Add more of this ingredient. Cut this ingredient out altogether.

Learning how Toyota operates or getting some form of agile certification is valuable information. It gives you some defaults and some experiments to run, and the chances are pretty good that you will see some movement toward your goal of greater agility.

But to get there, it's highly likely you will have to change the recipe, because following it to the letter may be harmful. Like any master chef, you need to feel free to experiment!